Optimizations around noexcept()

Hello.

A couple of question regarding how clang can optimize code with the C++11 noexcept specification.

1) If I understand correctly, if zero cost exceptions are used, the speed of the call should be the same
even if the compiler does know that the function doesn't throw. However, does this information enable
optimizations around the function call? Which kind of optimizations can be enabled with this assumption?

2) I suppose the noexcept specification is lowered to the nounwind LLVM attribute, correct me if this is wrong or
incomplete. However, I've seen llvm correctly adding the nounwind attribute to functions that it can prove don't throw.
Thus, is noexcept worth something in terms of performance (I'm not talking about maintainability here) if all the function code
can be seen by the call site and nounwind can be inferred? In the case of a header only template library, where all the code
can be seen in each compilation unit, this is the common case (but I suppose the same applies to any other kind of code if compiled
with -O4).

Thank you very much,
Nicola

Hello.

A couple of question regarding how clang can optimize code with the C++11 noexcept specification.

1) If I understand correctly, if zero cost exceptions are used, the speed of the call should be the same
even if the compiler does know that the function doesn't throw. However, does this information enable
optimizations around the function call? Which kind of optimizations can be enabled with this assumption?

I won’t fully answer your question, but I can tell you that the LLVM IR optimizer can hoist a potentially unsafe load out of a loop if that loop contains readonly, nounwind call. However, if the call is not readonly (may modify memory), then there’s isn’t much the low-level optimizer can do.

If you have a try block or destructors that need to run, then the ability to throw an exception isn’t really zero-cost. I would expect to see a bigger performance difference in that case, although haven’t analyzed this myself.

-Andy