[PATCH] D61669: [ValueTracking] Look through ptrmask intrinsics during getUnderlyingObject.
Florian Hahn via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jul 3 11:05:28 PDT 2019
fhahn marked an inline comment as done.
fhahn added inline comments.
================
Comment at: llvm/lib/Analysis/ValueTracking.cpp:3702
+ Call->getIntrinsicID() == Intrinsic::ptrmask;
}
----------------
jdoerfert wrote:
> aqjune wrote:
> > I found that `getArgumentAliasingToReturnedPointer` (which calls this function) is used at `isKnownNonZero` with the following pattern:
> >
> > ```
> > if (const auto *RP = getArgumentAliasingToReturnedPointer(Call))
> > return isKnownNonZero(RP, Depth, Q);
> > ```
> >
> > which seems to assume that the non-zeroness of the result of a function call is equivalent to the non-zeroness of the first argument. `isKnownNonZero` should be fixed, or maybe we can add a boolean flag to `isIntrinsicReturningPointerAliasingArgumentWithoutCapturing` that allows callers to determine its purpose?
> `Value::stripPointerCasts()` is sometimes used with the same assumption but there is it also not given (due to address space casts). In D61607 I try to introduce a version that "keeps the bit pattern the same" to fix uses that put the result in to `isKnownNonZero`-like functions.
>
> That said, I guess you can introduce an
> `isIntrinsicReturningPointerArgumentWithoutCapturing`
> to fix this issue?
Sorry for the long delay! I've added a MustPreserveNullness argument in D64150, to distinguish those 2 cases.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D61669/new/
https://reviews.llvm.org/D61669
More information about the llvm-commits
mailing list