[LLVMdev] C as used/implemented in practice: analysis of responses

[Joerg Sonnenberger]

On Wed, Jul 01, 2015 at 03:20:16PM +0100, Russell Wallace wrote:
> 1. The performance gain from this on real programs is small. I will suggest
> that the total performance gain from optimisations that rely on exploiting
> undefined behaviour - let's call them monkey's paw optimisations for short
> - is practically never more than a few percent, and often less than one
> percent.

This is blatantly wrong. There are quite a few things where hot code
would get seriously penalized if you want to "fix" UB. A very basic
example is over-large shifts. If the compiler can't prove that the shift
is within the size of the type, it would have to add additional branches
on at least one major CPU architecture as x86 and ARM implement
different results in that case. There is code where such additional
branches is providing a significant penalty. It is just one example.

If you say "performance gains from artifical UB", you might get more
agreement. The aggressive nonnull optimisations are likely a good
candidate here. I do hope that the definition of what is UB and what not
can be changed in the C standard, but there are still limits. What
happens on access to a NULL pointer should remain UB as the behavior
does differ between embedded systems and a desktop/server environment
using virtual memory with page protection.

Joerg