[PATCH] D66461: [CaptureTracker] Comparisons of allocation pointers do not capture

[Johannes Doerfert via Phabricator via llvm-commits]

jdoerfert added a comment.

In D66461#1639801 <https://reviews.llvm.org/D66461#1639801>, @efriedma wrote:

> Yes, you can't capture a pointer that's already captured.
>
> > ! In D66461#1640565 <https://reviews.llvm.org/D66461#1640565>, @hfinkel wrote:
> >  If you compare the same pointer (or derived from the same), you need to capture at least one from them "explicitly" to learn the bits.
>
> Yes, but then we'd need some way to account for that. If pointer A is compared to pointer B, and then pointer B is unambiguously captured, then so has been pointer A (at least in the part of the control flow dominated by the true edge of the comparison).


You can capture A that way if A and B are (basically) equal. Now in the part in which the capture of A through the icmp matters you already have B captured for sure, that is an alias of A is captured so A is captured even if not directly through the expression of A.

> The more interesting scenario is something like this: suppose you have three consecutive 16-byte allocations, laid out one after another.  The first and the third are captured; the second is not.  Can you capture a pointer to the second allocation using comparisons against the first and third allocations?  I think the only reasonable answer here is yes; you've proven the value of every bit of the pointer.
> 
> It doesn't really matter if three allocations don't reliably produce this layout; for any particular run of the program, we have to choose some memory layout.

I see your point but I think the basic idea is still sound, the patch needs an addition though.
As I described, the compare will capture only if the other pointer was captured. So additionally to the checks in the patch ask the tracker if that is the case, e.g.,

  if (IsDerefOrNoAlias0 && IsDerefOrNoAlias1)
    if (!Tracker->capture(Op1))
        break;

Maybe we can even get rid of the categories and say sth along the lines of:

  // Op0, the use of V in the ICmp is capturing if Op1 is captured. Otherwise,
  // Op1 is opaque and comparing it with another opaque pointer is not going
  // to yield information.
  if (!Tracker->capture(Op1)
     break;

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66461