[llvm-dev] Exceptions and performance

[David Blaikie via llvm-dev]

On Thu, Aug 13, 2020 at 2:59 PM Haoran Xu via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hello,
>
> I have been long taught that exceptions are considered the bad parts in the design of C++ language, and one should avoid using it since it's hard to write exception-safe code (I have no disagreement on this part) and it impedes compiler optimization.
>
> However, when recently I dig into the implementation of exception handling mechanism in LLVM recently, my impression is that using exceptions should instead improve performance (in the common case that no exception is thrown out), compared with the traditional approach of returning an error code in every function that can fail: no error-code-checking logic is executed in the fastpath, and error-handling code are moved from the main binary to the exception table, so the CPU is doing less work, and also instruction cache locality should be improved. Is my understanding correct?

(this is probably a bit too broad a topic for this forum/tends to end
up in heated discussions, etc, but let's see how we go)

I believe one of the main reasons your understanding there might be
incorrect: Not every function returns an error code. But essentially
every function can throw (yes, you can annotate them - but it's one of
those cases where C++ may've got the defaults wrong (like const, etc)
and it's impractical/unlikely someone's going to effectively maintain
noexcept on most of their codebase (and there are performance problems
with noexcept - since it's not UB to throw from such a function, it's
guaranteed to call terminate, so you have to generate exception
handling code in every noexcept function))

> So my question is:
> (1) Is the argument that 'exception hurts compiler optimization, and should not be used in perf-sensitive code' outdated now?

I don't believe so - having every function call being potentially
control flow changing inhibits certain optimizations that would
otherwise be possible (certain code motion, reordering, etc can't be
done) compared to a relatively smaller number of explicit
error-handling calls.

>  Or more generally, what are the pros and cons of using exception vs error code, from a LLVM backend developer's perspective?

Exceptions inhibit code motion, but allow for smaller code/keeping the
cold path/handling further away. I think that's basically the
mechanical tradeoff (setting aside issues of readability,
maintainability, etc - having an explicit keyword/notation on calls
that can throw could help a lot from a maintainability perspective,
for instance)

> (2) In current LLVM design, is there still any optimization that is prevented by using exceptions? Or is the current LLVM already able to provide the same optimization quality for code using exceptions, compared with code that does not?

I believe that exceptions do still hinder optimizations when compared
to code that doesn't throw or use a return code*. While that may seem
like an unfair comparison, it's my understanding that it's part of the
excessive cost of exceptions. Not to mention how expensive they can be
when they are thrown, compared to explicit error handling.

* Note this isn't a case of missed optimization opportunities (well,
perhaps in LTO it's a missed opportunity - if we did whole program
analysis to prove certain call trees never throw in practice, then we
could propagate that information and improve optimizations) - but a
limitation of exceptions.

- Dave