[PATCH] D65296: [Attributor] Loop Abstract Attribute
Johannes Doerfert via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 30 21:09:38 PDT 2019
jdoerfert added a comment.
In D65296#1603832 <https://reviews.llvm.org/D65296#1603832>, @lebedev.ri wrote:
> Please note that endless loops in itself is not UB in IR.
Correct.
One way to generate UB is through accesses or control involving poison.
What I wanted us to do is derive "not endless" for the following kinds of loops:
int s = ...
while (s++) ...; // overflow -> poison value -> poison in control
while (s + NonZero != N) ...; // overflow -> poison value -> poison in control
while (s * NonOneNonZero != N) ...; // overflow -> poison value -> poison in control
...
while (...)
access A[s++] // overflow -> poison value -> poison access address
unsigned u = ...;
while (...)
access A[u++] // Assuming NULL is not a valid pointer && "alignment of %ptr" modulo "sizeof(*ptr)" == 0
while (...)
access A[u++] // not strictly UB, depending on the types, but reasonable to exploit anyway (I think), potentially under a flag)
(I use signed/unsigned as an alternative to nsw/nuw in the GEP/add.)
We have helpers to determine poison and poison propagation (I think). For now, I'd be fine with the easy cases
`for (int i = ...; i cmp ...; i++) { ... }` and ``for (int i = ...; ...; i++) { ... A[i] ... }`
(Must-be-executed is can/should potentially be used here as well.)
> For example, alloca in the loop would cause UB but what information this gives us
Arguably, it would not be UB even if every implementation has limited memory. The problem is, I think, that a failed allocation alone is not UB.
Even if we have accesses on that allocation (which I doubt we find in the wild anyway), we would be in the same case as the last example above, not actually UB.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D65296/new/
https://reviews.llvm.org/D65296
More information about the llvm-commits
mailing list