[llvm-dev] Unsigned int displaying as negative

[Ryan Taylor via llvm-dev]

Where do in-tree archs handle the difference in this example? The
difference being printed either the signed or unsigned value.

Thanks.

On Wed, Feb 15, 2017 at 1:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:

> 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/d133e606/attachment.html>