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
