Re: IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?

[Sandra Loosemore <sandra@codesourcery.com>]

On 07/29/2011 12:13 PM, Vladimir Makarov wrote:
> On 07/27/2011 05:59 PM, Sandra Loosemore wrote:
>>
>> [snip]
>>
>> So, here's my question. Is it worthwhile for me to continue this
>> approach of trying to make the MIPS backend smarter? Or is the way IRA
>> deals with CANNOT_CHANGE_MODE_CLASS fundamentally broken and in need
>> of fixing in a target-inspecific way? And/or is there some other
>> regression in IRA on mainline that's causing it to spill to memory
>> when it didn't used to in 4.6?
>>
> I think the second ("fixing in a target-inspecific way"). Instead of
> prohibiting class for a pseudo (that what is happening for class
> FP_REGS) because the pseudo can change its mode, impossibility of
> changing mode should be reflected in the class cost (through some reload
> cost evaluation).
>
> I'll try to fix it. The only problem is that it will take sometime
> because the fix should be tested on a few platforms. It would be nice to
> make PR not to forget about the problem.

Thanks for offering to look into this.  I created

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936

with my test case and WIP patch for the MIPS backend.  At this point I'm 
thinking that the additional memory spills I'm seeing on mainline are 
not related to CANNOT_CHANGE_MODE_CLASS at all but are just some other 
regression in the register allocator compared to 4.6.  It might be 
useful to try to confirm/isolate that problem first.

-Sandra