<div dir="ltr"><div>Thanks for your reply.</div><div><br></div><div>We are propagating sign info to tablegen currently using BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm.</div><div><br></div><div>I imagine (I have not looked) they are printed according to instruction in AsmPrinter.cpp (pure speculation).</div><div><br></div><div>I'm still confused as to why 0x7FFF is ok to match 16 bit int but not 0x8000?</div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 1:44 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">Hi Ryan,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Manuel</font></span><div><div class="h5"><br>
<br>
On 2017-02-15 19:19, Ryan Taylor via llvm-dev wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
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 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></div></div><span>
______________________________<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>
</span></blockquote>
</blockquote></div><br></div>