[cfe-dev] Can noexcept impair performance?

John McCall rjmccall at apple.com
Fri Feb 15 10:23:11 PST 2013


On Feb 15, 2013, at 5:58 AM, Stephan Tolksdorf <st at quanttec.com> wrote:
> 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?

The frontend makes a simple first pass, but otherwise yes, I think so.  I don't know whether PruneEH actually kills off the dead exception handling code, but it's primarily responsible for making it dead.

>> 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.

Alas, that is how the language is specified.  In some common cases, of course, we can eliminate the null-check.

John.



More information about the cfe-dev mailing list