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

[Russell Wallace]

On Tue, Jun 30, 2015 at 6:21 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> We exploit undefined behavior because it helps to optimize real programs
> and shrink the size of generated code.
>

That is the reason compilers exploit undefined behaviour even when they are
generating code for a vanilla architecture with a flat address space, yes.
However, I will suggest:

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.

2. For most programs, having the program work is worth far more than having
it run a few percent faster.

3. If you look at the survey answers, it's clear that most real programs,
whether deliberately or accidentally, invoke undefined behaviour at some
point. You could say this is the programmer's fault, but in practice,
miscompiling a program typically punishes people other than the programmer
who wrote the code in question (and who may at this stage be long gone).
Furthermore, so little behaviour is actually defined by the letter of the C
and C++ standards, that the probability of even a team of highly skilled
and conscientious programmers writing a million line program without ever
invoking undefined behaviour is for all practical purposes zero.

I am frankly of the opinion that monkey's paw optimisations cause so much
trouble and are so difficult (for all practical purposes impossible) to
avoid tripping over, that it would be better to remove them entirely, but
given that compiler maintainers are clearly unwilling to do that, I propose
the following compromise:

Group all monkey's paw optimisations together, and enable them only if an
extra compiler flag is supplied. Or failing that, at least have a compiler
flag that will disable all of them (while leaving all the safe
optimisations enabled).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/05a0db2e/attachment.html>