[llvm-dev] Unsigned int displaying as negative

[Manuel Jacob via llvm-dev]

On 2017-02-15 19:54, Ryan Taylor wrote:
> Thanks for your reply.
> 
> We are propagating sign info to tablegen currently using
> BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm.

Note that this flag doesn't indicate signedness of the operation.  It 
just means that the optimizer or code generator can assume that no 
signed overflow will happen during the operation.  To get a better 
understanding of why this flag is not suitable for reconstructing the 
signedness of an operation (which is actually inherently 
signedness-agnostic), imagine an instruction that has both the 
NoSignedWrap and NoUnsignedWrap flags set.  What would be the 
"signedness" of this instruction?  This question doesn't have an answer, 
because adds don't have "signedness" when using two's complement.

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

I'm not quite sure what you're referring to.

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

I can't answer this question without knowing how your patterns look like 
exactly, but possibly this happens specifically because you try to 
propagate sign info (which doesn't really work, as explained above).

> 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
>>> 
>>