Hello!<div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>1) introduce new intrinsics 'llvm.ctz' and 'llvm.clz' which will have the desired new semantics (eventually)</div><div>2) teach codegen to treat these as *exactly* the same as the existing intrinsics</div>
<div>3) teach the rest of LLVM to treat them as aliases for the originals (now that they will be codegenned correctly)</div><div>4) switch frontends to use the new names when the new semantics are desirable</div><div>5) add auto-upgrade logic to convert the old intrinsics in IR to the new ones plus an explicit test for zero</div>
<div>6) switch the LLVM documentation to talk only about the new ones, and their new semantics</div><div>6b) add release notes about this somewhere?</div><div>7) remove all support (other than auto-upgrade) for the old intrinsics</div>
<div>8) change the middle end optimizers and codegen of the new intrinsics to take advantage of the new, narrower semantics</div><div>9) profit!!!</div><div><br></div><div>Sound like a good plan of attack? I've attached the patches for 1, 2, and 3; these were highly mechanical. Let me know if I can switch to post-commit review for this at any point, and/or if there are particular steps that should get extra close review or a announcement.</div>
<div>-Chandler</div>