<div class="gmail_quote">On Thu, Dec 1, 2011 at 11:20 AM, Dan Gohman <span dir="ltr"><<a href="mailto:gohman@apple.com">gohman@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="im">On Dec 1, 2011, at 2:47 AM, Chandler Carruth wrote:<br>
><br>
</div><div class="im">> 7) remove all support (other than auto-upgrade) for the old intrinsics<br>
<br>
</div>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.</blockquote><div><br></div><div>These instructions aren't widely available however, and as a consequence of their rarity (and the GCC builtins), the overwhelming majority of the code I've looked at using these has been tuned to preclude the possibility of zero already (or to discard the result if in fact a zero is present).</div>
<div><br></div><div>So I don't really have a problem requiring a branch in the IR and letting codegen match these away. Currently, this will be rare as most programs have already dealt with this and don't really care.</div>
<div><br></div><div>Given an algorithm which does not need the zero-defined behavior, the encoding for the old instructions is also smaller (based on my very limited understanding of the Intel docs).</div></div>