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

[Benjamin Kramer]

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.

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.