[PATCH] Fix assertion failure caused by InlineCost when ptrtoint int size is larger than the pointer size

Matt Arsenault arsenm2 at gmail.com
Thu Aug 15 11:33:00 PDT 2013


On Aug 15, 2013, at 11:24 , Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Thu, Aug 8, 2013 at 11:04 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:
> On Aug 8, 2013, at 0:36 , Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> >  I don't think this is the correct fix. Your original message indicates there something wrong with tracking a base and offset through an integer that happens to be wider than necessary for the pointer value?
> It's more that it's different and not that it's bigger. stripAndComputeInBoundsConstantOffsets returns a constant integer that is the pointer size, and is kept in the ConstantOffsetPtrs. In the test case, when the sub is visited, it uses those 32-bit constants for constant simplified value. This simplified value is then 32 bits which is inconsistent with its uses. When the simplified value is used when visiting the icmp, it isn't the same type as the i64 other operand.
> 
> So, somewhere in the original code, there is a 32-bit -> 64-bit extension (ptrtoint, or zext, or sext, or ?) that feeds into the icmp. At that point, we should extend the constant and should use the extended constant when visiting the icmp.
> 
> Again, I can't give more detailed help w/o a test case.
The test case is the one I added, the ptrtoint_larger one
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130815/e7645ee1/attachment.html>


More information about the llvm-commits mailing list