A Question About LRA/reload

Jeff Law law@redhat.com
Tue Dec 9 17:56:00 GMT 2014


On 12/09/14 10:10, Vladimir Makarov wrote:
> generate the correct code in many cases even for x86.  Jeff Law tried
> IRA coloring reusage too for reload but whole RA became slower (although
> he achieved performance improvements on x86).
Right.  After IRA was complete, I'd walk over the unallocated allocnos 
and split their ranges at EBB boundaries.  That created new allocnos 
with a smaller conflict set and reduced the conflict set for the 
original unallocated allocnos.

After I'd done that splitting for all the EBBs, I called back into 
ira_reassign_pseudos to try to assign the original unallocated allocnos 
as well as the new allocnos.

To get good results, much of IRA's cost analysis had to be redone from 
scratch.  And from a compile-time standpoint, that's a killer.

The other approach I was looking at was a backwards walk through each 
block.  When I found an insn with an unallocated pseudo that would 
trigger one of various range spliting techniques to try and free up a 
hard register.  Then again I'd call into ira_reassign_pseudos to try the 
allocations again.  This got even better results, but was obviously even 
more compile-time expensive.

I don't think much, if any, of that work is relevant given the current 
structure and effectiveness of LRA.

jeff



More information about the Gcc mailing list