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 12/10/14 02:02, Ajit Kumar Agarwal 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.

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.
It was focused on allocnos which were live at EBB boundaries and splitting the ranges at those boundaries.

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.



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.
The conflict graph was incrementally updated IIRC. The compile-time issues were mostly to get the register classes and ira cost models accurate.

Jeff


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