On 05/31/2013 02:40 AM, Lawrence Crowl wrote:
> On 5/30/13, Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
>> Can we quantify what we give up if we model current hardware
>> behavior more closely?
>
> Consider a program that adds a constant to a signed integer
> in a loop. Under the current model, the compiler can assume
> that the variable is monotonically increasing, and can therefore
> eliminate comparisons, which leads to simpler loops, which leads
> to vectorization, which leads to implementation in GPUs, ....
> Without that assumption, the chain of optimizations disappears.

Let's be specific (plus I think we should come up with a better
example):

  for (short i = 0; i >= 0; ++i)
     something(i);
  something_else();


 - With current C++, the compiler can assume this is a
non-terminating loop.

 - The user probably expected to iterate through the positive
values of a "short", i.e. the user expected one particular
implementation of signed integer overflow.

 - Removing "something_else()" from the generated assembly
is a valid optimization for the compiler today, but I posit
is in no case useful to the user.

 - The code as written appears to be a software (portability)
bug. There may be platforms where signed integer overflow
yields a hardware trap, and the code won't be reasonable there,
at all. (For this specific case, if all platforms currently
existing do the obvious wrap-around implementation, we could
nail down the semantics.)

 - This is similar to figure 4 in the paper
"Undefined Behavior: What Happened to My Code?"

 - What I actually want in this case is a diagnostic that an
optimization decision is made due to reliance on (local)
undefined behavior. From my (non-implementer) standpoint,
if a compiler implements an optimization, it should be able
to warn about the fact that it uses that optimization to remove
"real" source code.

 - The code snippet above, and a lot of similar cases, are not
hard to fix, but require source code changes to make them
conforming (i.e. portable).

> We really won't know the true tradeoff on real code until such
> optimizations are widely deployed.

Similar to strict alias analysis, which was made available in
gcc a few years ago, it seems people only clean up their code
after they've been bitten by their optimizer.

> My hope for SG12 was to get a clear understanding of the risks
> and benefits of undefined behavior. At present, the C++ community
> seem to be filled with fear of the risks, with no understanding of
> the benefits. The risks and benefits may vary between different
> language features, so I expect the present state to change.

Ok. It would be helpful if the benefits were more visible to users,
for example if users would get more diagnostics when the compiler
relies on undefined behavior. (gcc has -Wstrict-aliasing and
-Wstrict-overflow, for example.)

> One good result from SG12 is a list of features that have more than
> one possible outcome, so that programmers have a better understanding
> of when their programs stray from perfectly portable.

That would be the minimum output, yes. We need such a list anyway to
perform a case-by-case analysis / evaluation of the risk / benefit
ratio you mentioned above.

Jens