[PATCH] D65296: [Attributor] Loop Abstract Attribute

[Johannes Doerfert via Phabricator via llvm-commits]

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