<div class="gmail_quote">On Thu, Dec 1, 2011 at 3:06 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5"><br>
On Dec 1, 2011, at 11:20 AM, Dan Gohman wrote:<br>
<br>
> On Dec 1, 2011, at 2:47 AM, Chandler Carruth wrote:<br>
>><br>
>> 7) remove all support (other than auto-upgrade) for the old intrinsics<br>
><br>
> The "old" semantics really are more desirable though, in general. The only<br>
> reason I know of for the "new" semantics is to cater to x86's old bsf and<br>
> bsr instructions. But x86 admits its own deficiency, and has since introduced<br>
> the lzcnt and tzcnt instructions, which behave properly. It seems unfortunate<br>
> to require people who want the sane semantics to use a branch (even if<br>
> CodeGen is clever and can eliminate it).<br>
<br>
</div></div>I would be fine with keeping the existing intrinsics and adding two new ones with gcc-compatible semantics.<br>
<br>
How about llvm.ctlz.undef0 or something like that?</blockquote><div><br></div><div>To me, this is a bit gross... It makes the IR less minimalist and pure. Specifically, why have 2 extra intrinsics when a branch and an intrinsic are perfectly sufficient? I'm not claiming I *like* the fact that common hardware provides the undef-at-zero behavior and thus the intrinsic's semantics are a bit odd, but I like having two ways to write the same code in the IR significantly less.</div>
<div><br></div><div>Still, someone other than me should make the call on what the IR should look like. I've given my 2-cents, and now I just want to finish implementing it... But I'd like to avoid lots of churn renaming things 2 and 3 times so I'll wait for a decision here.</div>
</div>