llvm dev - Jul 2015 - [LLVMdev] C as used/implemented in practice: analysis of responses

> 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.
Which may or may not be fine until you decide to switch
compilers/platforms. Encouraging programmers to use Clang-specific
interpretations of these constructs would promote vendor lock-in and
be a blow for portability, which I think is worse than UB. At least
now we can tell people "you're doing it wrong".

Cheers.

Tim.

Not all code needs to be moved between compilers.

That having been said, if my proposal were implemented, you would still be
perfectly free to tell people 'you're doing it wrong, you shouldn't
actually depend on things the standard doesn't cover' (even though in
practice, people use compiler extensions, system specific code and suchlike
all the time, and nobody seems to think this is a reason such things
shouldn't be provided).

Even if you want to have the compiler warn at compile time about code that
depends on undefined behaviour (in cases where it can deduce that such is
occurring), that's okay.

But having programs miscompiled so that they silently fail, in many cases
starting only years after the code in question was written, is very much
not okay. That's far worse than documented portability problems.

On Wed, Jul 1, 2015 at 7:08 PM, Tim Northover <t.p.northover at gmail.com>
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.
> >
> > 2. For most programs, having the program work is worth far more than
> having
> > it run a few percent faster.
>
> Which may or may not be fine until you decide to switch
> compilers/platforms. Encouraging programmers to use Clang-specific
> interpretations of these constructs would promote vendor lock-in and
> be a blow for portability, which I think is worse than UB. At least
> now we can tell people "you're doing it wrong".
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/122ab860/attachment.html>

> But having programs miscompiled so that they silently fail, in many cases
> starting only years after the code in question was written, is very much
not
> okay. That's far worse than documented portability problems.
When given a certain spin...

Tim.