[LLVMdev] "icmp sgt" when it should be "ugt" ?

[Jonas Gefele]

Hi all,

thanks for your quick and helpful replies. Pointing me/us to the
"inbounds" has solved my confusion, as I originally had the exactly the
same concerns as Duncan.

Eli: I just rescanned the documentation of "getelementptr" and it really
doesn't say anything about (un)signedness of the indeces. The only
reference I've found is in "What happens if a GEP computation overflows?"
of the FAQ. So, maybe a short note in the reference could be useful.

Duncan: in the documentation of "ptrtoint" there is an implicit hint that
pointers are unsigned: "If value is smaller than ty2 then a zero extension
is done". Additionally, the above mentioned entry in the FAQ sheds a
little more light on it.

Cheers,
Jonas


> On Aug 2, 2011, at 8:53 AM, Duncan Sands wrote:
>
>> 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?
>
>
> It's a mix of both.
>
> Indices are signed, but the other operand is a pointer, and pointers
> can be interpreted in a variety of ways. On one hand, pointers are
> unsigned, since SIZE_MAX/2 and SIZE_MAX/2+1 are contiguous addresses,
> while SIZE_MAX and SIZE_MAX+1 are not, because address 0 is special.
> On the other hand, it's generally considered to be impossible to
> allocate more than half the address space to a single object, so it
> often works to analyze them as if they were signed.
>
> Dan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>