A Question About LRA/reload

shmeel gutl shmeelgutl@shmuelhome.mine.nu
Tue Dec 9 21:48:00 GMT 2014

On 09-Dec-14 07:56 PM, Jeff Law wrote:
> 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
Are any of these versions available? I wouldn't mind a 50% penalty in 
compile time if it gave me a 5% improvement in the generated code.

More information about the Gcc mailing list