On 5/30/13, Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
> 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.

Or at least terminates with exit, abort, or exception.

> - 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.

Possibly. They could have forgot a check. Or perhaps they
forgot to make something take a reference parameter. E.g.
void something(int i) { if ( i > 1000 ) i = -1; }

> - 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.

Exactly. Removing the dead code requires determining a static
property that permits it. If that static property derives from
undefined behavior, the compiler should warn.

> - 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).

In this case, changing integer overflow to wrap rather than be
undefined only fixes the bug if the programmer intended to wrap
the count. If the bug was elsewhere, as in my example, then we have
lost the opportunity to diagnose the problem, and simply shifted
from one symptom to another.

>
>> 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.

It is harder to warn on the effects of strict alias analysis.

>> 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.)

Ageed.

>> 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.

-- 
Lawrence Crowl