[llvm-dev] Unsigned int displaying as negative

[Ryan Taylor via llvm-dev]

Right, I understand that.

So why is 0x7FFF matching fine but not 0x8000 both fit in 16 bit?

Thanks.

On Wed, Feb 15, 2017 at 1:24 PM, Reid Kleckner <rnk at google.com> wrote:

> LLVM IR integers have no sign. You can't reliably tell whether an add or
> subtract was signed or unsigned when generating code.
>
> On Wed, Feb 15, 2017 at 10:19 AM, Ryan Taylor via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I'm curious why 'unsigned short w = 0x8000' is displayed as -32768 in the
>> IR?
>>
>> This propagates to the DAG and hence tablegen, where I am missing
>> matching on some immediates because the immediate is not being looked at as
>> unsigned? For example, we have no issue if instead of 0x8000 we use 0x7FFF,
>> then everything is fine, the match is fine.
>>
>> I can understand that it's just being printed as 'signed' even when it's
>> unsigned due to the bit pattern (2s complement)  but it seems to affect
>> matching.
>>
>> We'd like;
>>
>> unsigned short x, y;
>> int main() {
>>    unsigned short w = 0x8000;
>>    y = w - x;
>>    return 0;
>> }
>>
>> To match to something like 'sub16u $0x8000, x, y' (if I set w = 0x7FFF,
>> then we get sub16u $0x7FFF, x, y' but not when using 0x8000).
>>
>> We have some code to determine if the operation is a signed or unsigned
>> operation in tablegen. Can anyone suggest a good way to get around this?
>>
>> Thanks,
>> Ryan
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170215/1ef2d0a2/attachment.html>