<div dir="ltr"><div>Where do in-tree archs handle the difference in this example? The difference being printed either the signed or unsigned value.</div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 1:28 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>Right, I understand that.</div><div><br></div><div>So why is 0x7FFF matching fine but not 0x8000 both fit in 16 bit?</div><div><br></div><div>Thanks.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 1:24 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.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">LLVM IR integers have no sign. You can't reliably tell whether an add or subtract was signed or unsigned when generating code.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_389475750588209724h5">On Wed, Feb 15, 2017 at 10:19 AM, Ryan Taylor via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> 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="m_389475750588209724h5"><div dir="ltr"><div>I'm curious why 'unsigned short w = 0x8000' is displayed as -32768 in the IR?</div><div> </div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>We'd like;</div><div><br></div><div>unsigned short x, y;</div><div>int main() {</div><div>   unsigned short w = 0x8000;</div><div>   y = w - x;</div><div>   return 0;</div><div>}</div><div><br></div><div>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).</div><div><br></div><div>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? </div><div><br></div><div>Thanks,</div><div>Ryan</div></div>
<br></div></div>______________________________<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></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>