This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: A Question About LRA/reload
- From: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>
- To: Jeff Law <law at redhat dot com>, Vladimir Makarov <vmakarov at redhat dot com>, "lin zuojian" <manjian2006 at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 10 Dec 2014 09:02:31 +0000
- Subject: RE: A Question About LRA/reload
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 149.199.60.83) smtp dot mailfrom=ajit dot kumar dot agarwal at xilinx dot com;
- References: <20141209093747 dot GA25618 at ubuntu> <54872D05 dot 9060605 at redhat dot com> <548737C6 dot 20302 at redhat dot com>
-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Jeff Law
Sent: Tuesday, December 09, 2014 11:26 PM
To: Vladimir Makarov; lin zuojian; gcc@gcc.gnu.org
Subject: Re: A Question About LRA/reload
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.
Jeff: In the above approach of splitting the ranges for unallocated allocnos is aggressive or based on the approach
of some heuristics that the Live ranges for unallocated allocnos is not touched inside the EBBs.
>>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.
After the above splitting, are you building the conflict graph again to assign the new allocnos. If the Conflict graph is built again,
this will affect the compile time.
Thanks & Regards
Ajit
I don't think much, if any, of that work is relevant given the current structure and effectiveness of LRA.
jeff