<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This patch implements the current consensus of PR8973:<div> <a href="http://llvm.org/bugs/show_bug.cgi?id=8973">http://llvm.org/bugs/show_bug.cgi?id=8973</a>.<div><br></div><div>The macro llvm_unreachable is used in LLVM to indicate that</div><div>a particular place in a function is not supposed to be reachable</div><div>during execution. Like an assert macro, it takes a string</div><div>argument. In +Asserts builds, this string argument, together with</div><div>some location information, is passed to a function which prints</div><div>the information and calls abort(). In -Asserts builds, this string</div><div>argument is dropped (to minimize code size impact), and</div><div>instead a bunch of zero arguments are passed to the same</div><div>function.</div><div><br></div><div>The problem is that that's still not very good for code size, as it</div><div>leaves a somewhat bulky function call in the emitted code. It</div><div>also doesn't let give the compiler any opportunity to optimize</div><div>based on our assertion that the code is unreachable. A much</div><div>better alternative is to use an intrinsic, provided by Clang and</div><div>GCC 4.5, called __builtin_unreachable; it has the semantics</div><div>of being undefined behavior if reached, much like LLVM's own</div><div>"unreachable" instruction, which incidentally is what Clang</div><div>generates for it.</div><div><br></div><div>This patch keeps the old behavior of llvm_unreachable in</div><div> +Asserts (!defined(NDEBUG)) builds, but changes the behavior</div><div>in -Asserts builds to call __builtin_unreachable() (in GCC 4.5</div><div>and Clang) or abort() (in everything else).</div></div><div><br></div><div>This is effectively a change in the practical semantics of</div><div>llvm_unreachable: if the call is actually reachable, then you</div><div>will get some really crazy behavior in -Asserts builds. If you've</div><div>been using this macro in places that can logically be reached —</div><div>e.g., after you've tested for all the instructions you've actually</div><div>implemented in your backend — then you've been violating the</div><div>spirit of this macro, as communicated by its name, and you</div><div>should change your code to handle unexpected patterns</div><div>more responsibly.</div><div><br></div><div>John.</div><div><br></div><div></div></body></html>