<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 26, 2012, at 2:38 PM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Thu, Jan 26, 2012 at 2:14 PM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com">bob.wilson@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 id=":419">Make clz/ctz builtins defined for zero on ARM targets. <a href="rdar://10732455">rdar://10732455</a><br>
<br>
ARM supports clz and ctz directly and both operations have well-defined<br>
results for zero. There is no disadvantage in performance to using the<br>
defined-at-zero versions of llvm.ctlz/cttz intrinsics. We're running into<br>
ARM-specific code written with the assumption that __builtin_clz(0) == 32,<br>
even though that value is technically undefined. The code is failing now<br>
because of llvm optimizations that are taking advantage of the undef<br>
behavior (specifically svn r147255). There's nothing wrong with that<br>
optimization on x86 where any incorrect assumptions about __builtin_clz(0)<br>
will quickly be exposed. For ARM, though, optimizations based on that undef<br>
behavior are likely to cause subtle bugs. Other targets with defined-at-zero<br>
clz/ctz support may want to override the default behavior as well.</div></blockquote></div><br><div>Ouch. I can't argue at all with the logic here, but this is a nasty, nasty minefield.</div><div><br></div><div>I wonder, would it be better to add new builtins to represent defined-at-zero semantics consistently on all platforms? Maybe we could get folks to switch to those (or at least start).</div></blockquote><div><br></div>Adding new built-ins would be a good idea, but I think this behavior should stay regardless. There is already code out there for ARM with bad assumptions, and if anyone wants to write code that is portable across other compilers for ARM, they will have to stick with the existing built-ins.</div><div><br><blockquote type="cite">
<div><br></div><div>Either way, please document this language extension really loudly, as it is a specific divergence from GCC's specification of the builtins, and the builtins are supposedly Clang providing a "faithful" emulation of GCC….</div>
</blockquote><br></div><div>How is it a divergence? GCC says that the values are undefined. This does not conflict with that. It makes no difference on ARM codegen so the only real effect is to disable optimizations that try to take advantage of that undef.</div><br></body></html>