This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A Question About LRA/reload


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]