<div dir="ltr"><div>Sorry, it should be:</div><div><br></div><div>defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs, GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>;<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <span dir="ltr"><<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>So just as a reference:</div><div><br></div><div>def simm16 : Operand<i16> {<br> let DecoderMethod= "DecodeSimm16";<br> let OperandType = "OPERAND_IMMEDIATE";<br>}</div><div><br></div><div>def uimm16 : Operand<i16> {<br> let PrintMethod = "printUnsignedImm";<br> let OperandType = "OPERAND_IMMEDIATE";<br>}<br></div><div><br></div><div>def immSExt16x : ImmLeaf<i16, [{ return isInt<16>(Imm); }]>;<br></div><div>def immZExt16x : ImmLeaf<i16, [{ return isUInt<16>(Imm); }]>;</div><div><br></div><div>defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs, GPRRegs, DSTRegs, i16, i16, i16, simm16, immZExt16x>;</div><div><br></div><div>multiclass ABD_NonCommutative<string asmstr, SDPatternOperator OpNode, RegisterClass srcAReg, RegisterClass srcBReg,<br> RegisterClass dstReg, ValueType srcAType, ValueType srcBType, ValueType dstType,<br> Operand ImmOd, ImmLeaf imm_type></div><div>{<br></div><div> ....<br></div><div> def IMM_MEM_MEM : SetABDIn<asmstr, ImmOd, memhx, memhx,<br> <wbr> [(directStore (dstType (OpNode imm_type:$srcA, (srcBType (load addr16:$srcB)))), addr16:$dstD)]>;</div><div> .....</div><div>}</div><div><br></div><div>class SetABDIn<string asmstr, DAGOperand srcA, DAGOperand srcB, DAGOperand dstD, list<dag> pattern><br> : A_B_D<(outs), (ins srcA:$srcA, srcB:$srcB, dstD:$dstD),<br> !strconcat(asmstr, "\t$srcA, $srcB, $dstD"), pattern, IIAlu><br>{<br> let mayStore = 1;<br> let mayLoad = 1;<br>}<br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 2:24 PM, Manuel Jacob <span dir="ltr"><<a href="mailto:me@manueljacob.de" target="_blank">me@manueljacob.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><span>On 2017-02-15 19:54, Ryan Taylor wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
Thanks for your reply.<br>
<br>
We are propagating sign info to tablegen currently using<br>
BinaryWithFlagsSDNode.Flags.ha<wbr>sNoSignedWrap atm.<br>
</blockquote>
<br></span>
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.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
I imagine (I have not looked) they are printed according to instruction in<br>
AsmPrinter.cpp (pure speculation).<br>
</blockquote>
<br></span>
I'm not quite sure what you're referring to.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
I'm still confused as to why 0x7FFF is ok to match 16 bit int but not<br>
0x8000?<br>
</blockquote>
<br></span>
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).<div class="m_-7009372652016472040HOEnZb"><div class="m_-7009372652016472040h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
Thanks.<br>
<br>
On Wed, Feb 15, 2017 at 1:44 PM, Manuel Jacob <<a href="mailto:me@manueljacob.de" target="_blank">me@manueljacob.de</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
Hi Ryan,<br>
<br>
It is important to get clear about that LLVM IR integers (and operations<br>
if they don't have to) have no sign. But IR integers have to be printed<br>
somehow and it was decided to print them as being signed.<br>
<br>
I'm not a SelectionDAG and tablegen expert really, but I'm sure it is the<br>
same in the code generator. Sometimes the signedness is important for an<br>
instruction because flags are affected. But I'm ignoring that for now, as<br>
they would be represented as llvm.*.with.overflow in the IR with explicit<br>
signedness.<br>
<br>
In cases where flags don't matter, just select the best instruction. I'd<br>
advise against trying to reconstruct the signedness of an operation.<br>
That's impossible to do in general and there's no good reason to do that.<br>
<br>
-Manuel<br>
<br>
<br>
On 2017-02-15 19:19, Ryan Taylor via llvm-dev wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
I'm curious why 'unsigned short w = 0x8000' is displayed as -32768 in the<br>
IR?<br>
<br>
This propagates to the DAG and hence tablegen, where I am missing matching<br>
on some immediates because the immediate is not being looked at as<br>
unsigned? For example, we have no issue if instead of 0x8000 we use<br>
0x7FFF,<br>
then everything is fine, the match is fine.<br>
<br>
I can understand that it's just being printed as 'signed' even when it's<br>
unsigned due to the bit pattern (2s complement) but it seems to affect<br>
matching.<br>
<br>
We'd like;<br>
<br>
unsigned short x, y;<br>
int main() {<br>
unsigned short w = 0x8000;<br>
y = w - x;<br>
return 0;<br>
}<br>
<br>
To match to something like 'sub16u $0x8000, x, y' (if I set w = 0x7FFF,<br>
then we get sub16u $0x7FFF, x, y' but not when using 0x8000).<br>
<br>
We have some code to determine if the operation is a signed or unsigned<br>
operation in tablegen. Can anyone suggest a good way to get around this?<br>
<br>
Thanks,<br>
Ryan<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" rel="noreferrer">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
<br>
</blockquote></blockquote>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>