[PATCH] D62939: Fix a bug w/inbounds invalidation in LFTR (was: Strengthen LFTR's ability to replace IVs)

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 11 15:08:18 PDT 2019


reames added a comment.

In D62939#1538744 <https://reviews.llvm.org/D62939#1538744>, @nikic wrote:

> Let me try to summarize all the problems we can run into and how they will be handled as of this patch. Thankfully, our IV always has the simple form `IV = {S,+,1}`. Then, there are the following cases:
>  ....
>
> 2. `S` may be poison. For pointers: Poison/UB check or prevent LFTR. For integers: **Not handled**. ...


Actually, think 'S' being poisoned is almost fully handled or maybe even fully handled.  If 'S' is poison, then IV must be poison on at least the first iteration. Given that, if we find a side effect which must execute on the path to our exit block, then we've proven we must have executed UB.  As such, the program is undefined and we have no further obligations.

The only case where this line of reasoning doesn't work is a) our exit itself isn't evaluated on the first iteration and b) there's some operation within the IV computation which 1) strips poison from a poison input and 2) contributes to the next iteration of the IV.

Do there even exist operations which perform (b)?  That would seem to be a contradiction.

If there aren't, then we're fully covered.  If there are, then we'd need to find a UB operation on the path to the backedge to ensure poison on a prefix of the iteration space (only) is covered.  This would be easy to implement, though I'd prefer to do so in a separate change for sanity at this point.  :)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62939/new/

https://reviews.llvm.org/D62939





More information about the llvm-commits mailing list