<div dir="ltr"><div>Can you please give me an example (C code) where the nsw does not exist for signed operation?</div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 2:48 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Where does the unsignedSub come from?<div class="HOEnZb"><div class="h5"><br>
<br>
On 2017-02-15 20:38, Ryan Taylor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry, it should be:<br>
<br>
defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs,<br>
GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>;<br>
<br>
On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see. If I put simm16 and immSExt16x in place of uimm16 and immZExt16x<br>
respectively, the imm matches but it prints out -32768 (which is invalid<br>
for sub16u). We are using uimm16 not match unsigned but for PrintMethod,<br>
effectively uimm16 and simm16 are both Operand<i16>. I'm still unclear why<br>
simm16 matches and uimm16 does not. Here is the pattern if that helps at<br>
all.<br>
<br>
So just as a reference:<br>
<br>
def simm16 : Operand<i16> {<br>
let DecoderMethod= "DecodeSimm16";<br>
let OperandType = "OPERAND_IMMEDIATE";<br>
}<br>
<br>
def uimm16 : Operand<i16> {<br>
let PrintMethod = "printUnsignedImm";<br>
let OperandType = "OPERAND_IMMEDIATE";<br>
}<br>
<br>
def immSExt16x : ImmLeaf<i16, [{ return isInt<16>(Imm); }]>;<br>
def immZExt16x : ImmLeaf<i16, [{ return isUInt<16>(Imm); }]>;<br>
<br>
defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs,<br>
GPRRegs, DSTRegs, i16, i16, i16, simm16, immZExt16x>;<br>
<br>
multiclass ABD_NonCommutative<string asmstr, SDPatternOperator OpNode,<br>
RegisterClass srcAReg, RegisterClass srcBReg,<br>
RegisterClass dstReg, ValueType srcAType, ValueType<br>
srcBType, ValueType dstType,<br>
Operand ImmOd, ImmLeaf imm_type><br>
{<br>
....<br>
def IMM_MEM_MEM : SetABDIn<asmstr, ImmOd, memhx, memhx,<br>
[(directStore (dstType (OpNode<br>
imm_type:$srcA, (srcBType (load addr16:$srcB)))), addr16:$dstD)]>;<br>
.....<br>
}<br>
<br>
class SetABDIn<string asmstr, DAGOperand srcA, DAGOperand srcB, DAGOperand<br>
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>
<br>
<br>
On Wed, Feb 15, 2017 at 2:24 PM, Manuel Jacob <<a href="mailto:me@manueljacob.de" target="_blank">me@manueljacob.de</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2017-02-15 19:54, Ryan Taylor wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for your reply.<br>
<br>
We are propagating sign info to tablegen currently using<br>
BinaryWithFlagsSDNode.Flags.ha<wbr>sNoSignedWrap atm.<br>
<br>
</blockquote>
<br>
Note that this flag doesn't indicate signedness of the operation. It<br>
just means that the optimizer or code generator can assume that no signed<br>
overflow will happen during the operation. To get a better understanding<br>
of why this flag is not suitable for reconstructing the signedness of an<br>
operation (which is actually inherently signedness-agnostic), imagine an<br>
instruction that has both the NoSignedWrap and NoUnsignedWrap flags set.<br>
What would be the "signedness" of this instruction? This question doesn't<br>
have an answer, because adds don't have "signedness" when using two's<br>
complement.<br>
<br>
I imagine (I have not looked) they are printed according to instruction in<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
AsmPrinter.cpp (pure speculation).<br>
<br>
</blockquote>
<br>
I'm not quite sure what you're referring to.<br>
<br>
I'm still confused as to why 0x7FFF is ok to match 16 bit int but not<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
0x8000?<br>
<br>
</blockquote>
<br>
I can't answer this question without knowing how your patterns look like<br>
exactly, but possibly this happens specifically because you try to<br>
propagate sign info (which doesn't really work, as explained above).<br>
<br>
<br>
Thanks.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
Hi Ryan,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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<br>
the<br>
same in the code generator. Sometimes the signedness is important for<br>
an<br>
instruction because flags are affected. But I'm ignoring that for now,<br>
as<br>
they would be represented as llvm.*.with.overflow in the IR with<br>
explicit<br>
signedness.<br>
<br>
In cases where flags don't matter, just select the best instruction.<br>
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<br>
that.<br>
<br>
-Manuel<br>
<br>
<br>
On 2017-02-15 19:19, Ryan Taylor via llvm-dev wrote:<br>
<br>
I'm curious why 'unsigned short w = 0x8000' is displayed as -32768 in<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the<br>
IR?<br>
<br>
This propagates to the DAG and hence tablegen, where I am missing<br>
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<br>
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<br>
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>
<br>
</blockquote>
<br>
</blockquote></blockquote></blockquote></blockquote></blockquote>
</div></div></blockquote></div><br></div>