<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 21, 2014 at 9:39 AM, 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>So again, I'm not sure why this is the case. I know this has probably been discussed ad nauseam (as evidenced by the multiple posts asking about this, including mine), but it seems pretty clear cut that you'd want separate shl, one for logical (non-overflow) and one for arithmetic (overflow). In fact, you might want a logical, signed arith and unsigned arith, at least in the hardware. </div><div><br></div><div>I don't care if clang only produces shl, I'm more curious how to get the signed info to the backend for shl when it's not producing a nsw/nuw flag? I'm currently not sure how this would be done, is there another arch that manages this somehow?</div></div></blockquote><div><br></div><div>LLVM defines left shift overflow to produce an undefined value, so I don't think it matters which machine instruction you use to implement shl, as long as it doesn't trap. The user can't rely on the result being any thing in particular. You should be able to just always emit logical or arithmetic left shift and the program will behave correctly.</div><div><br></div><div>I think this is kind of like asking what to do with the 32 high bits in edx after 32-bit multiplication on x86. LLVM doesn't define a way to get at them, so you can just drop it on the floor. LLVM doesn't define what happens on shl overflow, so you can produce any result you like.</div></div></div></div>