[PATCH] D90610: [Inline] Fix in handling of ptrtoint in InlineCost

Mikael Holmén via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 3 00:07:16 PST 2020


uabelho marked 2 inline comments as done.
uabelho added inline comments.


================
Comment at: llvm/lib/Analysis/InlineCost.cpp:1124
+      else {
+        APInt OffsetWithCorrectSize = BaseAndOffset.second.sext(IntegerSize);
+        std::pair<Value *, APInt> BaseAndOffsetWithCorrectSize =
----------------
spatel wrote:
> bjope wrote:
> > spatel wrote:
> > > uabelho wrote:
> > > > I don't know if sext is what we want to do here, of it that may lead to problems?
> > > Signed math is what I would expect based on:
> > > http://llvm.org/docs/LangRef.html#getelementptr-instruction
> > > "These integers are treated as signed values where relevant."
> > > ...and we do similar in GEPOperator::accumulateConstantOffset() for example.
> > > 
> > Not sure exactly how these ConstantOffsetPtrs are used, but doesn't it matter that ptrtoint is defined as doing a zext if the integer size is greater than the size of the pointer (base+offset)?
> Hmm...yes, I think you're right:
> http://llvm.org/docs/LangRef.html#ptrtoint-to-instruction
> So disregard my GEP comment. It would be great to manufacture an example of this behavior, but I'm not sure how to do that.
Ok, so I changed to use zext.

I tried fiddling with testcases to try to find cases where I could see a difference between using sext and zext but I've failed.


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

https://reviews.llvm.org/D90610



More information about the llvm-commits mailing list