[PATCH] D13358: InstCombine: Fold comparisons between unguessable allocas and other pointers

Sanjoy Das via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 5 13:17:19 PDT 2015


sanjoy added a comment.

In http://reviews.llvm.org/D13358#259819, @hans wrote:

> > Right now GetUnderlyingObject does not look through PHI nodes, but if it starts to at some point, this change will fold %cmp [...]
>
>
> That would be correct, though. Or are you saying there's a problem there?


There's a //potential// problem here in justifying the transform -- in
the loop, the programmer is no longer doing a "one-off guess" anymore,
but systematically searching for the offset of a passed in argument
(which points to some slot in the caller's stack, say) from the
`alloca`.  For instance, such a loop can allow you to implement
pointer subtraction without `ptrtoint` -- `while (&ptra[diff++] != ptrb)`.

In other words, I understand the justification for the current change
to be that: an `alloca` can be allocated to any stack slot in the
current frame, so the compiler is allowed to fold any equality
comparisons to `false`.  This seems fine.  But a loop with an
incrementing induction variable can use an equality check to
"implement" an inequality check like `ult` or `slt`, and by folding
the `!=` to `true` in `while (&ptra[diff++] != ptrb)`, you're really
semantically folding `ptra < ptrb` to `false`.  I personally think
this is not a problem, but I hope I was able to communicate what the
difference is.


================
Comment at: lib/Transforms/InstCombine/InstCombineCompares.cpp:786
@@ +785,3 @@
+        return nullptr; // Found more than one cmp.
+      continue;
+    } else if (auto *Intrin = dyn_cast<IntrinsicInst>(V)) {
----------------
Ah, ok.  (This is completely optional) I'd be tempted to get rid of `NumCmps` and write the check as

```
if (U != AllocaUse)
  return nullptr;
```

where `AllocaUse` is the `Use *` of the `alloca` in `ICI` which you either pass in or compute.


http://reviews.llvm.org/D13358





More information about the llvm-commits mailing list