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

Matthias Braun via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 21 14:29:33 PDT 2016


MatzeB added a comment.

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

> The update in this patch is the complete handling of subregister live ranges (subranges of the main live interval) in live range splitting.  The live range extension code has been changed to allow extending to points where the live range is not reached by any def: doing so has no effect, but it allow speculative extensions for subranges, whose liveness is not known at the moment.
>
> The splitting code will only create and maintain liveness for subranges (for registers that have those).  The main range will be constructed after subrange updates are complete.
>
> If a new live range is created for a part of the original live range where only a part of the original register was defined, the new range will still have a "full size" register associated with it.  Since the boundary of the new live range will involve a copy or a spill of the whole register (which was only partially defined), if the new range was contained in a loop, the subrange information for the undefined parts will now contain instructions which were not included in the original live range.  Necessary changes were made to deal with such situations.
>
> The treatment of "undef" subregister definitions was updated to preserve liveness of the super-register: previously a <def,read-undef>of a subregister would be considered a "non-reading" def of the super-register.  If another subregister was defined prior to such a def and was live across it, this liveness would not be reflected in the super-register's live range.


I haven't looked at the actual patch yet, but this last paragraph sounds wrong to me. A <def,read-undef> does indeed not read the super register, this is exactly why we add the read-undef flag!


Repository:
  rL LLVM

http://reviews.llvm.org/D21189





More information about the llvm-commits mailing list