[PATCH] D93820: [InstSimplify] Don't fold gep p, -p to null

Ralf via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 11 03:00:01 PST 2021


RalfJung added a comment.

> + The base pointer has an in bounds address of the allocated object it is based on [...]

It's slightly more tricky than this. A wrong GEPi doesn't always immediately produce `poison`; instead it records (in the provenance) which offsets all have to be inbounds and then when a load/store happens, it causes UB if any of these offsets is not inbounds. So there are "doomed" pointers (that cause UB when dereferenced) that are not poison. They cannot be optimized to poison since they can still be legally used e.g. in "icmp".

All this is necessary since LLVM considers both inttoptr and GEPi pure operations that it will reorder across anything. To determine "the allocated object it (the pointer) is based on" we'd have to look up in memory which allocated object corresponds to this integer address, but that would make the operation impure and make the reorderings wrong. So instead determining which allocated object this ptr is based on is delayed until the next memory access.

> I think everyone agrees it's not legal for the non-inbounds case (and not legal for the non-null case regardless of inbounds)

For non-inbounds, I agree that "folding gep p, q-p to q is only legal if p and q have the same provenance" (so, barely ever).

I didn't entirely follow the "inbounds" arguments here, but I am happy to leave that to y'all. ;)


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

https://reviews.llvm.org/D93820



More information about the llvm-commits mailing list