[llvm-commits] PATCH: Initial patches for changing the semantics of llvm.cttz and llvm.ctlz
clattner at apple.com
Thu Dec 1 09:08:29 PST 2011
On Dec 1, 2011, at 2:47 AM, Chandler Carruth wrote:
> A while back Owen helped me track down a performance problem I had with some very hot encoding and decoding routines to the different semantics LLVM uses for '__builtin_ctz' and '__builtin_clz' compared to GCC. Specifically, GCC doesn't provide a defined result for an input of zero and LLVM does. On X86, this results in significantly worse code if the user has already ensured that a zero input will be caught elsewhere.
> Owen asked Chris if we could just switch LLVM's intrinsics to the narrower definition, and he was good with it. The idea was to also fix their naming to agree more with the common mnemonics and the builtins. Thus, my plan to resolve this is as follows:
> 1) introduce new intrinsics 'llvm.ctz' and 'llvm.clz' which will have the desired new semantics (eventually)
> 2) teach codegen to treat these as *exactly* the same as the existing intrinsics
> 3) teach the rest of LLVM to treat them as aliases for the originals (now that they will be codegenned correctly)
> 4) switch frontends to use the new names when the new semantics are desirable
> 5) add auto-upgrade logic to convert the old intrinsics in IR to the new ones plus an explicit test for zero
> 6) switch the LLVM documentation to talk only about the new ones, and their new semantics
> 6b) add release notes about this somewhere?
> 7) remove all support (other than auto-upgrade) for the old intrinsics
> 8) change the middle end optimizers and codegen of the new intrinsics to take advantage of the new, narrower semantics
> 9) profit!!!
The plan sounds good to me, and the first three patches seem fine. Please use your judgement about what needs precommit review.
The only part of this that I find unfortunate is that "llvm.clz" will end up inconsistently named with "llvm.ctpop".
More information about the llvm-commits