llvm dev - Aug 2011 - [LLVMdev] "icmp sgt" when it should be "ugt" ?

Hi Chris,
> Icmp sgt is correct.
while ugt would be wrong, I think sgt is too!

For example, suppose %buf is 0 and %bufLen is ~0U.  Then %add.ptr is ~0U, and
%cmp is true, so control branches to %if.then.  However in the optimized version
%cmp is false and control branches to %if.end.

The GEP does have an inbounds attribute, I'm not sure if that is relevant
here.

Ciao, Duncan.

   Note that "ugt x, 0" is the same as "x != 0" which is not
what you want.
>
> -Chris
>
> On Aug 1, 2011, at 9:11 AM, Jonas Gefele<llvm.org at schrieb.de> 
wrote:
>
>> Hello,
>>
>> while writing a new LLVM backend I have observed that in some cases the
>> optimizer produces an "icmp sgt i32 %a, 0" where I would have
expected an
>> "icmp ugt i32 %a, 0".
>>
>> For example when I feed "opt -O3 -S ..."  (LLVM 2.9, Windows)
with
>>
>>
>>
------------------------------------------------------------------------
>> target datalayout = "E-p:32:32:32"
>>
>> define void @foo(i8* %buf, i32 %bufLen, i32* %ret) nounwind {
>> entry:
>>   %add.ptr = getelementptr inbounds i8* %buf, i32 %bufLen
>>   %cmp = icmp ult i8* %buf, %add.ptr
>>   br i1 %cmp, label %if.then, label %if.end
>>
>> if.then:                                          ; preds = %entry
>>   store i32 0, i32* %ret
>>   br label %if.end
>>
>> if.end:                                           ; preds = %if.then,
%entry
>>   ret void
>> }
>>
------------------------------------------------------------------------
>>
>>
>> I get as output
>>
>>
>>
------------------------------------------------------------------------
>> ...
>> entry:
>>   %cmp = icmp sgt i32 %bufLen, 0
>>   br i1 %cmp, label %if.then, label %if.end
>> ...
>>
------------------------------------------------------------------------
>>
>>
>> This is no problem if one thinks of "icmp sgt %a, 0" as
"compute %a - 0
>> and set flags accordingly" because then signedness makes no
difference.
>> But if I understand things correctly, it is a problem according to the
>> LLVM IR reference which states "sgt: interprets the operands as
signed
>> values and yields true if op1 is greater than op2". Under this
definition
>> and for %a=0xFFFFFFFF "ugt" would return true while
"sgt" would return
>> false, wouldn't it?
>>
>> Is this a bug in my thinking, a bug in the reference manual, or is this
a
>> bug in some pass which introduces the "sgt"?
>>
>>
>> Cheers,
>> Jonas
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Tue, Aug 2, 2011 at 3:47 AM, Duncan Sands <baldrick at free.fr>
wrote:
> Hi Chris,
>
>> Icmp sgt is correct.
>
> while ugt would be wrong, I think sgt is too!
>
> For example, suppose %buf is 0 and %bufLen is ~0U.  Then %add.ptr is ~0U,
and
> %cmp is true, so control branches to %if.then.  However in the optimized
version
> %cmp is false and control branches to %if.end.
>
> The GEP does have an inbounds attribute, I'm not sure if that is
relevant here.
It is relevant: in your proposed scenario, the GEP returns undef.

-Eli

Hi Eli,
>>> Icmp sgt is correct.
>>
>> while ugt would be wrong, I think sgt is too!
>>
>> For example, suppose %buf is 0 and %bufLen is ~0U.  Then %add.ptr is
~0U, and
>> %cmp is true, so control branches to %if.then.  However in the
optimized version
>> %cmp is false and control branches to %if.end.
>>
>> The GEP does have an inbounds attribute, I'm not sure if that is
relevant here.
>
> It is relevant: in your proposed scenario, the GEP returns undef.
by the way, is GEP arithmetic supposed to be signed or unsigned?

The LangRef says: "...if any of the addresses that would be formed by
successive addition of the offsets implied by the indices to the base address
with infinitely precise arithmetic are not an in bounds address of that
allocated object".  But it doesn't say how the address (i.e. a number
in the
ring of integers mod 2^32) gets represented as an integer (presumably what the
"infinitely precise arithmetic" refers too).

For example, consider the address ~0U.  This could be represented by any of the
integers: ...-1 - 2^32, -1, 2^32 - 1 , 2*2^32 - 1, ...

If you choose -1, and also have an offset of -1, then the sum is -2 which may
well still be inside your object.  If you choose 2^32-1, and also 2^32-1 for
the offset, then the sum is 2*2^32-2, which presumably is not considered to be
inside your object (it would be if you reduced modulo 2^32, but then there
would be no point in using infinite precision arithmetic, so I suppose that that
is not what is intended).

Ciao, Duncan.