This is the mail archive of the
mailing list for the GCC project.
Re: A Question About LRA/reload
- From: shmeel gutl <shmeelgutl at shmuelhome dot mine dot nu>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 09 Dec 2014 23:48:31 +0200
- Subject: Re: A Question About LRA/reload
- Authentication-results: sourceware.org; auth=none
- References: <20141209093747 dot GA25618 at ubuntu> <54872D05 dot 9060605 at redhat dot com> <548737C6 dot 20302 at redhat dot com>
On 09-Dec-14 07:56 PM, Jeff Law wrote:
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.
On 12/09/14 10:10, Vladimir Makarov wrote:
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.
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).
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.