[PATCH] D21189: Create subranges for new intervals resulting from live interval splitting

Matthias Braun via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 24 14:46:43 PDT 2016


MatzeB added a comment.

In http://reviews.llvm.org/D21189#466724, @kparzysz wrote:

> In http://reviews.llvm.org/D21189#466699, @MatzeB wrote:
>
> > The register allocator is able to use the same physical register for vreg1 and vreg1 here (as there is never a point where both have sub0 or sub1 live at the same time).
>
>
> What I meant by "non-extendable" defs are defs that always remain dead in the live range, even if the flow of the program indicates that they could reach some use (in the same block, or not).  By keeping them that way, they would not occupy any additional space in the live range, so they could get redefined/reused in the "empty" space.  They would only serve as a barrier preventing a prior def from reaching any subsequent use.
>
> If the subranges were separated into individual virtual registers, the read-undef could become an IMPLICIT_DEF, at least temporarily, and it could be erased if possible.
>
> I believe that taking advantage of the situation that you mention above can only happen via register coalescing, and it already has some knowledge about implicit defs and invalidated lanes.  The code that joins live ranges could be extended to handle cases like that: a "non-extendable" dead def could be treated as a removable implicit-def (since the read-undef flag could be removed from the offending operand).  Wouldn't this be sufficient to avoid regressions?


I am thinking of this:

  10.  vreg1.sub1<read-undef> = ...
  20.  vreg0.sub0<read-undef> = ...
  30.    use vreg1.sub1
   ...
  100.   use vreg0.sub0

We would like the allocator to be able to assing the same physical (super) register to vreg0 and vreg1. However if we put a dead-def for vreg0.sub1 at 20 then the register allocator will see an interference with vreg1(.sub1) and will assign a different register to vreg1.


Repository:
  rL LLVM

http://reviews.llvm.org/D21189





More information about the llvm-commits mailing list