On 07/28/2011 02:11 AM, Richard Guenther wrote:
On Wed, Jul 27, 2011 at 11:59 PM, Sandra Loosemore
<san...@codesourcery.com> 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?
It sounds like IRA would benefit from properly split live-ranges here.
You could try
to make the fabs optabs magic make sure to use a new pseudo (well, and hope
that survives ...)
That was actually the first thing I tried, and it didn't work -- the new
pseudo was eliminated well before it got to the RA.
I was thinking vaguely that this could be fixed in IRA by having an
additional target hook to supply a reload register class to try for
cases where CANNOT_CHANGE_MODE_CLASS is true (typically GENERAL_REGS),
and from there making it treat this case the same as any other where it
has to reload to satisfy the constraints of some particular instruction.
Given that I know nothing about IRA at this point beyond the little
bit I picked up when trying to analyze this problem, that seems scarier
than just fixing it in the MIPS backend, but certainly not as scary as
adding stuff to split live ranges to IRA. :-)
Anyone else have thoughts about the best way to proceed here?
-Sandra
