llvm dev - Feb 2017 - Unsigned int displaying as negative

Where does the unsignedSub come from?

On 2017-02-15 20:38, Ryan Taylor wrote:
> Sorry, it should be:
> 
> defm SUB16u_  : ABD_NonCommutative<"sub16u", unsignedSub,
LOADRegs,
> GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>;
> 
> On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> 
> wrote:
> 
>> I see. If I put simm16 and immSExt16x in place of uimm16 and 
>> immZExt16x
>> respectively, the imm matches but it prints out -32768 (which is 
>> invalid
>> for sub16u). We are using uimm16 not match unsigned but for 
>> PrintMethod,
>> effectively uimm16 and simm16 are both Operand<i16>. I'm
still unclear
>> why
>> simm16 matches and uimm16 does not. Here is the pattern if that helps 
>> at
>> all.
>> 
>> So just as a reference:
>> 
>> def simm16      : Operand<i16> {
>>   let DecoderMethod= "DecodeSimm16";
>>   let OperandType = "OPERAND_IMMEDIATE";
>> }
>> 
>> def uimm16      : Operand<i16> {
>>   let PrintMethod = "printUnsignedImm";
>>   let OperandType = "OPERAND_IMMEDIATE";
>> }
>> 
>> def immSExt16x : ImmLeaf<i16, [{ return isInt<16>(Imm);
}]>;
>> def immZExt16x : ImmLeaf<i16, [{ return isUInt<16>(Imm);
}]>;
>> 
>> defm SUB16u_  : ABD_NonCommutative<"sub16u", unsignedSub,
LOADRegs,
>> GPRRegs, DSTRegs, i16, i16, i16, simm16, immZExt16x>;
>> 
>> multiclass ABD_NonCommutative<string asmstr, SDPatternOperator
OpNode,
>> RegisterClass srcAReg, RegisterClass srcBReg,
>>                RegisterClass dstReg, ValueType srcAType, ValueType
>> srcBType, ValueType dstType,
>>                Operand ImmOd, ImmLeaf imm_type>
>> {
>>      ....
>>      def IMM_MEM_MEM      : SetABDIn<asmstr, ImmOd, memhx, memhx,
>>                                 [(directStore (dstType (OpNode
>> imm_type:$srcA, (srcBType (load addr16:$srcB)))), addr16:$dstD)]>;
>>      .....
>> }
>> 
>> class SetABDIn<string asmstr, DAGOperand srcA, DAGOperand srcB, 
>> DAGOperand
>> dstD, list<dag> pattern>
>>             : A_B_D<(outs), (ins srcA:$srcA, srcB:$srcB,
dstD:$dstD),
>>             !strconcat(asmstr, "\t$srcA, $srcB, $dstD"),
pattern,
>> IIAlu>
>> {
>>     let mayStore = 1;
>>     let mayLoad = 1;
>> }
>> 
>> 
>> On Wed, Feb 15, 2017 at 2:24 PM, Manuel Jacob <me at
manueljacob.de>
>> wrote:
>> 
>>> 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
>>>>>> 
>>>>>> 
>>>>>

Can you please give me an example (C code) where the nsw does not exist for
signed operation?

Thanks.

On Wed, Feb 15, 2017 at 2:48 PM, Manuel Jacob <me at manueljacob.de>
wrote:
> Where does the unsignedSub come from?
>
>
> On 2017-02-15 20:38, Ryan Taylor wrote:
>
>> Sorry, it should be:
>>
>> defm SUB16u_  : ABD_NonCommutative<"sub16u", unsignedSub,
LOADRegs,
>> GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>;
>>
>> On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at
gmail.com> wrote:
>>
>> I see. If I put simm16 and immSExt16x in place of uimm16 and immZExt16x
>>> respectively, the imm matches but it prints out -32768 (which is
invalid
>>> for sub16u). We are using uimm16 not match unsigned but for
PrintMethod,
>>> effectively uimm16 and simm16 are both Operand<i16>. I'm
still unclear
>>> why
>>> simm16 matches and uimm16 does not. Here is the pattern if that
helps at
>>> all.
>>>
>>> So just as a reference:
>>>
>>> def simm16      : Operand<i16> {
>>>   let DecoderMethod= "DecodeSimm16";
>>>   let OperandType = "OPERAND_IMMEDIATE";
>>> }
>>>
>>> def uimm16      : Operand<i16> {
>>>   let PrintMethod = "printUnsignedImm";
>>>   let OperandType = "OPERAND_IMMEDIATE";
>>> }
>>>
>>> def immSExt16x : ImmLeaf<i16, [{ return isInt<16>(Imm);
}]>;
>>> def immZExt16x : ImmLeaf<i16, [{ return isUInt<16>(Imm);
}]>;
>>>
>>> defm SUB16u_  : ABD_NonCommutative<"sub16u",
unsignedSub, LOADRegs,
>>> GPRRegs, DSTRegs, i16, i16, i16, simm16, immZExt16x>;
>>>
>>> multiclass ABD_NonCommutative<string asmstr, SDPatternOperator
OpNode,
>>> RegisterClass srcAReg, RegisterClass srcBReg,
>>>                RegisterClass dstReg, ValueType srcAType, ValueType
>>> srcBType, ValueType dstType,
>>>                Operand ImmOd, ImmLeaf imm_type>
>>> {
>>>      ....
>>>      def IMM_MEM_MEM      : SetABDIn<asmstr, ImmOd, memhx,
memhx,
>>>                                 [(directStore (dstType (OpNode
>>> imm_type:$srcA, (srcBType (load addr16:$srcB)))),
addr16:$dstD)]>;
>>>      .....
>>> }
>>>
>>> class SetABDIn<string asmstr, DAGOperand srcA, DAGOperand srcB,
>>> DAGOperand
>>> dstD, list<dag> pattern>
>>>             : A_B_D<(outs), (ins srcA:$srcA, srcB:$srcB,
dstD:$dstD),
>>>             !strconcat(asmstr, "\t$srcA, $srcB, $dstD"),
pattern, IIAlu>
>>> {
>>>     let mayStore = 1;
>>>     let mayLoad = 1;
>>> }
>>>
>>>
>>> On Wed, Feb 15, 2017 at 2:24 PM, Manuel Jacob <me at
manueljacob.de> wrote:
>>>
>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170215/2b357873/attachment.html>

Or some C code where nsw would show up in an unsigned operation?

On Wed, Feb 15, 2017 at 2:48 PM, Manuel Jacob <me at manueljacob.de>
wrote:
> Where does the unsignedSub come from?
>
>
> On 2017-02-15 20:38, Ryan Taylor wrote:
>
>> Sorry, it should be:
>>
>> defm SUB16u_  : ABD_NonCommutative<"sub16u", unsignedSub,
LOADRegs,
>> GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>;
>>
>> On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at
gmail.com> wrote:
>>
>> I see. If I put simm16 and immSExt16x in place of uimm16 and immZExt16x
>>> respectively, the imm matches but it prints out -32768 (which is
invalid
>>> for sub16u). We are using uimm16 not match unsigned but for
PrintMethod,
>>> effectively uimm16 and simm16 are both Operand<i16>. I'm
still unclear
>>> why
>>> simm16 matches and uimm16 does not. Here is the pattern if that
helps at
>>> all.
>>>
>>> So just as a reference:
>>>
>>> def simm16      : Operand<i16> {
>>>   let DecoderMethod= "DecodeSimm16";
>>>   let OperandType = "OPERAND_IMMEDIATE";
>>> }
>>>
>>> def uimm16      : Operand<i16> {
>>>   let PrintMethod = "printUnsignedImm";
>>>   let OperandType = "OPERAND_IMMEDIATE";
>>> }
>>>
>>> def immSExt16x : ImmLeaf<i16, [{ return isInt<16>(Imm);
}]>;
>>> def immZExt16x : ImmLeaf<i16, [{ return isUInt<16>(Imm);
}]>;
>>>
>>> defm SUB16u_  : ABD_NonCommutative<"sub16u",
unsignedSub, LOADRegs,
>>> GPRRegs, DSTRegs, i16, i16, i16, simm16, immZExt16x>;
>>>
>>> multiclass ABD_NonCommutative<string asmstr, SDPatternOperator
OpNode,
>>> RegisterClass srcAReg, RegisterClass srcBReg,
>>>                RegisterClass dstReg, ValueType srcAType, ValueType
>>> srcBType, ValueType dstType,
>>>                Operand ImmOd, ImmLeaf imm_type>
>>> {
>>>      ....
>>>      def IMM_MEM_MEM      : SetABDIn<asmstr, ImmOd, memhx,
memhx,
>>>                                 [(directStore (dstType (OpNode
>>> imm_type:$srcA, (srcBType (load addr16:$srcB)))),
addr16:$dstD)]>;
>>>      .....
>>> }
>>>
>>> class SetABDIn<string asmstr, DAGOperand srcA, DAGOperand srcB,
>>> DAGOperand
>>> dstD, list<dag> pattern>
>>>             : A_B_D<(outs), (ins srcA:$srcA, srcB:$srcB,
dstD:$dstD),
>>>             !strconcat(asmstr, "\t$srcA, $srcB, $dstD"),
pattern, IIAlu>
>>> {
>>>     let mayStore = 1;
>>>     let mayLoad = 1;
>>> }
>>>
>>>
>>> On Wed, Feb 15, 2017 at 2:24 PM, Manuel Jacob <me at
manueljacob.de> wrote:
>>>
>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170215/04ac6429/attachment.html>

For every example we've seen, nsw is very consistent with signed operation.
I understand it's a 'potential for signed overflow' flag but it
seems very
consistent with signedness.

On Wed, Feb 15, 2017 at 2:48 PM, Manuel Jacob <me at manueljacob.de>
wrote:
> Where does the unsignedSub come from?
>
>
> On 2017-02-15 20:38, Ryan Taylor wrote:
>
>> Sorry, it should be:
>>
>> defm SUB16u_  : ABD_NonCommutative<"sub16u", unsignedSub,
LOADRegs,
>> GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>;
>>
>> On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at
gmail.com> wrote:
>>
>> I see. If I put simm16 and immSExt16x in place of uimm16 and immZExt16x
>>> respectively, the imm matches but it prints out -32768 (which is
invalid
>>> for sub16u). We are using uimm16 not match unsigned but for
PrintMethod,
>>> effectively uimm16 and simm16 are both Operand<i16>. I'm
still unclear
>>> why
>>> simm16 matches and uimm16 does not. Here is the pattern if that
helps at
>>> all.
>>>
>>> So just as a reference:
>>>
>>> def simm16      : Operand<i16> {
>>>   let DecoderMethod= "DecodeSimm16";
>>>   let OperandType = "OPERAND_IMMEDIATE";
>>> }
>>>
>>> def uimm16      : Operand<i16> {
>>>   let PrintMethod = "printUnsignedImm";
>>>   let OperandType = "OPERAND_IMMEDIATE";
>>> }
>>>
>>> def immSExt16x : ImmLeaf<i16, [{ return isInt<16>(Imm);
}]>;
>>> def immZExt16x : ImmLeaf<i16, [{ return isUInt<16>(Imm);
}]>;
>>>
>>> defm SUB16u_  : ABD_NonCommutative<"sub16u",
unsignedSub, LOADRegs,
>>> GPRRegs, DSTRegs, i16, i16, i16, simm16, immZExt16x>;
>>>
>>> multiclass ABD_NonCommutative<string asmstr, SDPatternOperator
OpNode,
>>> RegisterClass srcAReg, RegisterClass srcBReg,
>>>                RegisterClass dstReg, ValueType srcAType, ValueType
>>> srcBType, ValueType dstType,
>>>                Operand ImmOd, ImmLeaf imm_type>
>>> {
>>>      ....
>>>      def IMM_MEM_MEM      : SetABDIn<asmstr, ImmOd, memhx,
memhx,
>>>                                 [(directStore (dstType (OpNode
>>> imm_type:$srcA, (srcBType (load addr16:$srcB)))),
addr16:$dstD)]>;
>>>      .....
>>> }
>>>
>>> class SetABDIn<string asmstr, DAGOperand srcA, DAGOperand srcB,
>>> DAGOperand
>>> dstD, list<dag> pattern>
>>>             : A_B_D<(outs), (ins srcA:$srcA, srcB:$srcB,
dstD:$dstD),
>>>             !strconcat(asmstr, "\t$srcA, $srcB, $dstD"),
pattern, IIAlu>
>>> {
>>>     let mayStore = 1;
>>>     let mayLoad = 1;
>>> }
>>>
>>>
>>> On Wed, Feb 15, 2017 at 2:24 PM, Manuel Jacob <me at
manueljacob.de> wrote:
>>>
>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170215/f8287fe4/attachment.html>

On 15 February 2017 at 13:52, Ryan Taylor via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Can you please give me an example (C code) where the nsw does not exist for
> signed operation?
If you compile with -frwapv that's what you get. Earlier passes could
also quite easily add or remove those flags for whatever reason.

Tim.

If you want to see what happens, the transforms/* tests have examples where
nsw disappears.


On Wed, Feb 15, 2017 at 1:58 PM, Ryan Taylor via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> For every example we've seen, nsw is very consistent with signed
> operation. I understand it's a 'potential for signed overflow'
flag but it
> seems very consistent with signedness.
>
> On Wed, Feb 15, 2017 at 2:48 PM, Manuel Jacob <me at manueljacob.de>
wrote:
>
>> Where does the unsignedSub come from?
>>
>>
>> On 2017-02-15 20:38, Ryan Taylor wrote:
>>
>>> Sorry, it should be:
>>>
>>> defm SUB16u_  : ABD_NonCommutative<"sub16u",
unsignedSub, LOADRegs,
>>> GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>;
>>>
>>> On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at
gmail.com> wrote:
>>>
>>> I see. If I put simm16 and immSExt16x in place of uimm16 and
immZExt16x
>>>> respectively, the imm matches but it prints out -32768 (which
is invalid
>>>> for sub16u). We are using uimm16 not match unsigned but for
PrintMethod,
>>>> effectively uimm16 and simm16 are both Operand<i16>.
I'm still unclear
>>>> why
>>>> simm16 matches and uimm16 does not. Here is the pattern if that
helps at
>>>> all.
>>>>
>>>> So just as a reference:
>>>>
>>>> def simm16      : Operand<i16> {
>>>>   let DecoderMethod= "DecodeSimm16";
>>>>   let OperandType = "OPERAND_IMMEDIATE";
>>>> }
>>>>
>>>> def uimm16      : Operand<i16> {
>>>>   let PrintMethod = "printUnsignedImm";
>>>>   let OperandType = "OPERAND_IMMEDIATE";
>>>> }
>>>>
>>>> def immSExt16x : ImmLeaf<i16, [{ return
isInt<16>(Imm); }]>;
>>>> def immZExt16x : ImmLeaf<i16, [{ return
isUInt<16>(Imm); }]>;
>>>>
>>>> defm SUB16u_  : ABD_NonCommutative<"sub16u",
unsignedSub, LOADRegs,
>>>> GPRRegs, DSTRegs, i16, i16, i16, simm16, immZExt16x>;
>>>>
>>>> multiclass ABD_NonCommutative<string asmstr,
SDPatternOperator OpNode,
>>>> RegisterClass srcAReg, RegisterClass srcBReg,
>>>>                RegisterClass dstReg, ValueType srcAType,
ValueType
>>>> srcBType, ValueType dstType,
>>>>                Operand ImmOd, ImmLeaf imm_type>
>>>> {
>>>>      ....
>>>>      def IMM_MEM_MEM      : SetABDIn<asmstr, ImmOd, memhx,
memhx,
>>>>                                 [(directStore (dstType (OpNode
>>>> imm_type:$srcA, (srcBType (load addr16:$srcB)))),
addr16:$dstD)]>;
>>>>      .....
>>>> }
>>>>
>>>> class SetABDIn<string asmstr, DAGOperand srcA, DAGOperand
srcB,
>>>> DAGOperand
>>>> dstD, list<dag> pattern>
>>>>             : A_B_D<(outs), (ins srcA:$srcA, srcB:$srcB,
dstD:$dstD),
>>>>             !strconcat(asmstr, "\t$srcA, $srcB,
$dstD"), pattern, IIAlu>
>>>> {
>>>>     let mayStore = 1;
>>>>     let mayLoad = 1;
>>>> }
>>>>
>>>>
>>>> On Wed, Feb 15, 2017 at 2:24 PM, Manuel Jacob <me at
manueljacob.de>
>>>> wrote:
>>>>
>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>
> _______________________________________________
> 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/b3d322d9/attachment-0001.html>