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

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added inline comments.


================
Comment at: llvm/lib/Analysis/InlineCost.cpp:1124
+      else {
+        APInt OffsetWithCorrectSize = BaseAndOffset.second.sext(IntegerSize);
+        std::pair<Value *, APInt> BaseAndOffsetWithCorrectSize =
----------------
uabelho wrote:
> 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.
Just to clarify, I'm not sure zext is any better (or more correct). My point was that if you have `%x = ptrtoint %y` an `%y` is `%base + %offset`, then `zext(%base+%offset)` isn't neccessarily the same as `zext(%base) + zext(%offset)` (neither the same as `sext(%base) + sext(%offset)`). Unless maybe if these base&offset pairs are guaranteed to be inbound or non-wrapping/non-overflowing or something? Maybe that is implied?


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

https://reviews.llvm.org/D90610