[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