[PATCH] D152241: [CaptureTracking] Do not capture compares of same object

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 7 08:25:42 PDT 2023


nikic added a comment.

In D152241#4402472 <https://reviews.llvm.org/D152241#4402472>, @goldstein.w.n wrote:

> In D152241#4402421 <https://reviews.llvm.org/D152241#4402421>, @nikic wrote:
>
>> Using getUnderlyingObject() here is not quite right: The underlying object is a pure provenance notion, while icmp is a pure address comparison. What we need here is that the icmp can be expressed as `Base + Offset1 == Base + Offset2`. This is *nearly* what getUnderlyingObject() does in practice, but not quite.
>>
>> In particular, getUnderlyingObject() can also look through ptrmask intrinsics. However, `ptrmask(P, M) == P` clearly leaks bits of the pointers.
>
> The case being because depending on `M` is indicates which bits in `P` are zero?
> If so then I think you can only do this for equality comparisons, otherwise something like:
> `Base + Offset1 < Base + Offset2` can probably end up leaking some bits (depending on what is known
> about Offset1/Offset2) because of overflows.
> If that is a concern then you need to also ensure the `ICmp` is equality (its unchecked at the moment).

Yes, you are right, this also needs to check for equality comparisons. I believe it can be extended to unsigned predicates if the GEPs are inbounds, but let's start simple here...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152241



More information about the llvm-commits mailing list