[PATCH] D59065: [BasicAA] Simplify inttoptr(and(ptrtoint(X), C)) to X, if C preserves all significant bits.

Juneyoung Lee via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 1 02:38:55 PDT 2019


aqjune added a comment.

@fhahn

> In the example, the original pointer (`%addr = load %struct.zot*, %struct.zot** %loc, align 8`) is not dereference directly and the use case I am looking at is tagged pointers, where the inttoptr(and(ptrtoint(), C) roundtrip is required to get a valid pointer.  So the original pointer might not be dereferenceable directly, but logically (ignoring the bits irrelevant for the pointer value) it should still point to the same object.  Does that make sense to you?

The problem happens when `%addr` is untagged and not dereferenceable.
For example, given an array `int a[4]`, `&a[4]` is not dereferenceable, but `(int *)(int)&a[4]` may update another object that is adjacent to `a[4]`.
IIUC, if `getUnderlyingObject(p)` returns an object `obj`, modifying `p` should either only update `obj` or raise undefined behavior, but is unallowed to modify other objects.
If `%addr = &a[4]`, it is incorrect for `getUnderlyingObject(inttoptr(and(ptrtoint %addr, C)))` to return `a`.
If there is a guarantee that the object `%addr` points to is still alive and `inttoptr(and(ptrtoint %addr, C))` is within the object (e.g. `a[0], .., a[3]`), the analysis is correct.

@atrick

In D59065#1449489 <https://reviews.llvm.org/D59065#1449489>, @atrick wrote:

> @sanjoy I haven't tried to solve this problem myself, but it seems pretty important. It sounds to me like you're laying out an argument for introducing LLVM pointer masking intrinsics that would preserve some sort of inbound property. Is it fair to say that we probably can't fully optimize tagged pointers without using intrinsics to avoid this ptrtoint optimizer trap?


I think your understanding is correct. To support full optimization opportunity, an intrinsic like `llvm.ptrmask(p, mask)` would work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59065





More information about the llvm-commits mailing list