[llvm-commits] [llvm] r150978 - /llvm/trunk/lib/Transforms/InstCombine/InstCombineCompares.cpp

Nick Lewycky nicholas at mxc.ca
Tue Feb 21 22:28:38 PST 2012


Benjamin Kramer wrote:
>
> On 21.02.2012, at 12:11, Duncan Sands wrote:
>
>> Hi Benjamin,
>>
>>>>> InstCombine: Removing the base from the address calculation is only safe when the GEPs are inbounds.
>>>>
>>>> since GEP is implicitly a signed computation, isn't this only true for signed
>>>> comparisons?  I.e. mightn't an inbounds GEP overflow when viewed as an unsigned
>>>> computation, leading to wrongness for unsigned comparisons?
>>>
>>> Not sure if I understand. We're folding this to an index compare so the resulting icmp will always be signed. Also, overflow on inbounds GEPs is undefined behavior.
>>
>> what does "overflow" mean?  Suppose a pointer has 8 bits, so the values are:
>>
>> -128, -127, ..., -1, 0, 1, ..., 127
>>
>> Can I have an object that spans addresses -1, 0, 1?  Can I have an object that
>> occupies addresses 127 and -128?  If either of these is yes, then we had better
>> be allowing inbounds GEP that (in the first case) has an unsigned overflow, and
>> (if the second case is allowed) signed overflow.

Hold up. My understanding was no object can lie across -1,0 or 127,-128 
in LLVM. Am I mistaken? Is there documentation on this point? If not, 
could this please be documented?

> After some discussion on IRC it became clear that this transformation is not valid for signed ICMPs.
> I added a check for them and some explanation in r151055.
>
> Thanks Duncan!
>
> - Ben
>
>>
>> Ciao, Duncan.
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>




More information about the llvm-commits mailing list