[cfe-dev] Can noexcept impair performance?

[Stephan Tolksdorf]

On 2013-02-11, John McCall wrote:
> On Feb 10, 2013, at 7:11 AM, Stephan Tolksdorf <st at quanttec.com> wrote:
[...]
>> I wonder whether there are also situations where a noexcept declaration could impair performance. For example, I could imagine that a noexcept declaration might complicate or even suppress inlining if the compiler can't prove that the function code can never throw. Could this happen with Clang?
>
> Exception specifications can impair performance in two ways:
> 1.  Exception specifications are required to be enforced, so if a noexcept function calls anything that isn't noexcept, the compiler has to emit exception tables and handlers to ensure that std::terminate is called, increasing code size.  (GCC-compatible personality functions support an abbreviation for this handler so that, in theory, the compiler need not use an actual landing pad.  However, clang does not currently take advantage of this.)

Thank you for the explanation!

Would it be correct to state that it's the job of LLVM's PruneEH pass 
(which runs before the inliner) to remove the exception handling 
overhead associated with a function exception specifications if it 
detects in a bottom-up traversal of the call-graph that the function can 
not throw an exception?

> 2.  When an operator new is noexcept, new expressions are required to check whether the result is null before calling the constructor.  This introduces an extra branch on every allocation.  Sadly, this applies even to the special global placement operator new.

Requiring a low-level primitive like placement new to do an implicit 
null check indeed seems to be unnecessarily inefficient. If you wanted 
the null check, you could easily perform it yourself before calling 
placement new.

- Stephan