This is the mail archive of the
mailing list for the GCC project.
Re: A Question About LRA/reload
- From: Jeff Law <law at redhat dot com>
- To: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx 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 12:38:28 -0700
- 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> <8dc29378d49a4e7e9e9df61a5758ff1b at BY2FFO11FD018 dot protection dot gbl>
On 12/10/14 02:02, Ajit Kumar Agarwal wrote:
It was focused on allocnos which were live at EBB boundaries and
splitting the ranges at those boundaries.
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
In the case where the allocno was live across the EBB, but not used/set
in the EBB, the split effectively homes the allocno in its stack slot
across those EBBs. That reduces the conflicts for the original allocno
(and possibly other allocnos that need hard registers).
You can actually use that property to free up hard registers as well.
If there's allocno(s) which are not used/set in an EBB, but which got a
hard register, you can split their range at the EBB boundary. This
results in those allocnos homing into their stack slot across those EBBs
(or some other hard register). Which in turn frees one or more hard
registers within the EBB.
In fact, you can take that concept quite a bit further and use it as the
fundamental basis for range splitting by simply changing the range over
which you want the allocnos to be transparent. The range could be an
EBB, BB a few insns or a single insn.
And that was the basis for backwards walk through the BB approach I was
experimenting with. We just walked insns backwards in the BB, when we
encountered an insn with an unallocated allocno, we split the range of
some other allocno to free up a suitable hard register. First we'd look
for an allocno that was transparent across the EBB, then a BB, then the
largest range from the insn needing the reload to the closest prior
use/set. By splitting across these larger ranges, we tended to free up
a hard register over a large range and it could often be used to satisfy
multiple unassigned allocnos. I was in the process of refactoring the
code to handle things like register pairs and such when I got pulled
away to other things. I don't recall if this variant was ever
bootstrapping, but it was getting great fill rates compared to reload.
The conflict graph was incrementally updated IIRC. The compile-time
issues were mostly to get the register classes and ira cost models accurate.
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.