[llvm-commits] [llvm] r132732 - /llvm/trunk/utils/TableGen/FastISelEmitter.cpp

[David Blaikie]

>
> Ahh.. yes, I misunderstood your example.  Here are the source comments,
> which best explain the use of llvm_unreachable:
>
> */// Marks that the current location is not supposed to be reachable.**/// In !NDEBUG builds, prints the message and location info to stderr.**/// In NDEBUG builds, becomes an optimizer hint that the current location**/// is not supposed to be reachable.  On compilers that don't support**/// such hints, prints a reduced message instead.**///**/// Use this instead of assert(0).  It conveys intent more clearly and**/// allows compilers to omit some unnecessary code.*
>
> In the case of a release build an unreachable hint is emitted.  The
> compiler then uses this hint to transform:
>
>       } else if (Operands[i].isFP()) {
>         OS << "ConstantFP *f" << i;
>       } else {
>         llvm_unreachable("Unknown operand kind!");
>       }
>
> to:
>
>       } else if (Operands[i].isFP()) {
>         OS << "ConstantFP *f" << i;
>       }
>
> I hope this helps answer your question.  In the end the compiler is being
> smart about removing the unreachable code.  For more details you could also
> checkout: http://www.nondot.org/sabre/LLVMNotes/UnreachableInstruction.txt
>

Ah, ok - thanks for the explanation. I didn't realize llvm_unreachable was
that advanced/involved (though I suppose I Should've expected as much).

So both versions (the assert & the unreachable) seem to have similar
semantics (performance & correctness) given a sufficiently advanced compiler
(that uses the unreachable to remove the isFP() call) - makes sense.

[is there any policy/recommendations on which way to go in this case? I
guess it's not a problem to leave this up to the author of any particular
piece of LLVM code about which expression they prefer/find more clear in a
given situation]

Thanks again for the help,
- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110610/1437bc51/attachment.html>