[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