<div dir="ltr"><div>Tim, yes, I am on a very unique architecture, just about every instruction has a signed and unsigned operation (ie, adds, addu, subs, subu, etc...) and we handle signed and unsigned somewhat differently.</div><div><br></div><div>I'm not sure how we'll handle this yet, very worst case scenario is to propagate the info from clang but that's not ideal, obviously.</div><div><br></div><div>Thanks for all the replies!</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 5:16 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15 February 2017 at 10:19, Ryan Taylor via llvm-dev<br>
<span><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<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>
</span>I still think this is the basic problem. Unless you're on a really<br>
weird architecture it really doesn't matter whether an<br>
originally-written operation was signed or unsigned (with the<br>
already-represented exception of sdiv/udiv). It's probably best to<br>
take a step back and reassess this rather than ploughing on trying to<br>
preserve long-departed information.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>