[PATCH] D26359: Use LiveRangeCalc to extend live ranges in shrinkToUses

Krzysztof Parzyszek via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 8 06:46:52 PST 2016


kparzysz added a comment.

In https://reviews.llvm.org/D26359#616745, @MatzeB wrote:

> Can explain why reusing the existing VNI objects is not possible?


LiveRangeCalc cannot have pre-existing PHI defs in the live range (for reasons explained in the comment).  When extending a range, it will allocate new VNInfo objects for the PHIs that it creates.  This will cause the actual VNInfo pointers to differ between the old range and the freshly extended one.  My understanding here is that shrinkToUses is expected to preserve those pointers, and at least for PHI values, this is impossible to do when using LiveRangeCalc.  Because of that I wrote the "transferSegments" function that adjusts the old live range to match the extended one, while still using the original VNs from the old range.

I did some experiments with deleting certain segments (those starting at block boundaries) while keeping the VNInfo list, and then having LiveRangeCalc use these values when extending the range.  The problem was that such a LiveRange object was then temporarily "invalid" (because of the missing segments for certain values), and I kept running into assertions failing because of that.  What I didn't like about this approach was that it required changes in LiveRangeCalc to accommodate this unique mode of operation (in addition to simply allocating new VNs when needed), but it was the assertions that made me decide that this wasn't worth the effort.  In the end I decided (as you observed) to simply create a new live range, extend it, and then map it back into the old one.

The pattern "traverse all register uses and collect slot indexes" does indeed appear in several places and can likely be reused.  I actually thought about it, but I didn't want to make this patch too large.  If you think it's a good idea, I can look into it.


Repository:
  rL LLVM

https://reviews.llvm.org/D26359





More information about the llvm-commits mailing list