[llvm-commits] PATCH: Initial patches for changing the semantics of llvm.cttz and llvm.ctlz

[Chandler Carruth]

On Thu, Dec 1, 2011 at 3:06 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Dec 1, 2011, at 11:20 AM, Dan Gohman wrote:
>
> > On Dec 1, 2011, at 2:47 AM, Chandler Carruth wrote:
> >>
> >> 7) remove all support (other than auto-upgrade) for the old intrinsics
> >
> > The "old" semantics really are more desirable though, in general. The
> only
> > reason I know of for the "new" semantics is to cater to x86's old bsf and
> > bsr instructions. But x86 admits its own deficiency, and has since
> introduced
> > the lzcnt and tzcnt instructions, which behave properly. It seems
> unfortunate
> > to require people who want the sane semantics to use a branch (even if
> > CodeGen is clever and can eliminate it).
>
> I would be fine with keeping the existing intrinsics and adding two new
> ones with gcc-compatible semantics.
>
> How about llvm.ctlz.undef0 or something like that?


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20111201/9da4493d/attachment.html>