llvm dev - Feb 2017 - Unsigned int displaying as negative

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170215/59de3a10/attachment.html>

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

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>

Hi Ryan,

It is important to get clear about that LLVM IR integers (and operations 
if they don't have to) have no sign.  But IR integers have to be printed 
somehow and it was decided to print them as being signed.

I'm not a SelectionDAG and tablegen expert really, but I'm sure it is 
the same in the code generator.  Sometimes the signedness is important 
for an instruction because flags are affected.  But I'm ignoring that 
for now, as they would be represented as llvm.*.with.overflow in the IR 
with explicit signedness.

In cases where flags don't matter, just select the best instruction.  
I'd advise against trying to reconstruct the signedness of an operation. 
  That's impossible to do in general and there's no good reason to do 
that.

-Manuel

On 2017-02-15 19:19, Ryan Taylor via llvm-dev 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

Thanks for your reply.

We are propagating sign info to tablegen currently using
BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm.

I imagine (I have not looked) they are printed according to instruction in
AsmPrinter.cpp (pure speculation).

I'm still confused as to why 0x7FFF is ok to match 16 bit int but not
0x8000?

Thanks.

On Wed, Feb 15, 2017 at 1:44 PM, Manuel Jacob <me at manueljacob.de>
wrote:
> Hi Ryan,
>
> It is important to get clear about that LLVM IR integers (and operations
> if they don't have to) have no sign.  But IR integers have to be
printed
> somehow and it was decided to print them as being signed.
>
> I'm not a SelectionDAG and tablegen expert really, but I'm sure it
is the
> same in the code generator.  Sometimes the signedness is important for an
> instruction because flags are affected.  But I'm ignoring that for now,
as
> they would be represented as llvm.*.with.overflow in the IR with explicit
> signedness.
>
> In cases where flags don't matter, just select the best instruction. 
I'd
> advise against trying to reconstruct the signedness of an operation.
> That's impossible to do in general and there's no good reason to do
that.
>
> -Manuel
>
>
> On 2017-02-15 19:19, Ryan Taylor via llvm-dev 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/c1a14e79/attachment.html>

On 15 February 2017 at 10:19, Ryan Taylor via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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?
I still think this is the basic problem. Unless you're on a really
weird architecture it really doesn't matter whether an
originally-written operation was signed or unsigned (with the
already-represented exception of sdiv/udiv). It's probably best to
take a step back and reassess this rather than ploughing on trying to
preserve long-departed information.

Tim.

Tim, yes, I am on a very unique architecture, just about every instruction
has a signed and unsigned operation (ie, adds, addu, subs, subu, etc...)
and we handle signed and unsigned somewhat differently.

I'm not sure how we'll handle this yet, very worst case scenario is to
propagate the info from clang but that's not ideal, obviously.

Thanks for all the replies!



On Wed, Feb 15, 2017 at 5:16 PM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> On 15 February 2017 at 10:19, Ryan Taylor via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 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?
>
> I still think this is the basic problem. Unless you're on a really
> weird architecture it really doesn't matter whether an
> originally-written operation was signed or unsigned (with the
> already-represented exception of sdiv/udiv). It's probably best to
> take a step back and reassess this rather than ploughing on trying to
> preserve long-departed information.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170215/27ef6e43/attachment.html>