[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 12:48:44 PDT 2016


MatzeB added a comment.

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

> With this interpretation of <def,read-undef>, there is a problem in extending live ranges:
>
>   16 vreg0<def> = ...
>   24 ... = vreg0<kill>
>   ...
>   64 vreg0:sub0<def,read-undef>
>   72 ... = vreg0
>
>
> Suppose that vreg0 has two lanes: L1 and L2, corresponding to sub0 and sub1.  When creating the live ranges, after the dead defs have been created, but before extending to uses, the live range for L2 will be simply [16r,16d). There will be no indication in there that the value defined at 16 should not be extended to the use at 72.
>
> What I'm considering is to treat <def,read-undef> of a lane as if it was an IMPLICIT_DEF of all other lanes.  In other words, a <def,read-undef> would add a def to all subranges, not only the one corresponding to the specified subregister.  In the example above, the live range for L2 will be [16r,16d)[64r,64d).  Now, that will prevent the def at 16 from reaching the use at 72. Instead, the def at 64r will reach it (in the same fashion as a def produced by an IMPLICIT_DEF would).
>
> What are your thoughts about it?  There are a few places in the code that will need to be made aware of this (register coalescer is one of them).  Do you have any other suggestions?


I think I've been running in to the same problems before when working with subreg liveness. And so far I mostly dodged it by not trying to recompute liveness past the register coalescer. After coming fresh out of SSA form before the coalescer the live ranges are always simply enough that you cannot run into this problem.

Ideally we would have lane masks on every machine operand to specify which lanes are unused or dead. This would solve this recomputation problem cleanly (in your example above we would mark the L2 lane as unused). It would also simply and speedup RegisterOperands::adjustLaneLiveness() in RegisterPressure.cpp.
Unfortunately we would increase the size of the MachineOperands which from what I hear dominate the memory usage in the backend, so I am not sure if this solution is acceptable for the community.

Considering def,read-undef as an implicit-def would give us conservatively correct live ranges. However I fear that we will regress register allocation, they will block registers even when the value turns out never to be read. Maybe if we had a way to clean extra unused dead-defs...


Repository:
  rL LLVM

http://reviews.llvm.org/D21189





More information about the llvm-commits mailing list