On Wed, Sep 21, 2011 at 3:25 PM, David Blaikie <[email protected]> wrote:
> One other point on this - the issues you've raised already exist in both > assert and llvm_unreachable code, making this change (assert(0) -> > llvm_unreachable) somewhat orthogonal to them. > Not at all. llvm_unreachable has a tremendously different impact in optimized builds than assert(0) does. The latter has zero impact, the control flow remains as expected. But llvm_unreachable tells the optimizer that this code path *cannot be taken*. That in turn constrains the value of the input. That in turn causes other optimizations to fire, and so on. This can cause essentially unbounded undefined behavior given an unexpected input, where as the assert will "merely" fall through. I've specifically seen cases in the disassembler and assembler code where truly unexpected cases are assert(0)'ed, but then handled benignly. I don't think we want to tell the optimizer that this *cannot* happen, but rather catch when it does happen in our test suite. The assert seems well suited to that.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
