On 10/24/13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> Jean-Marc Bourguet <jm_at_[hidden]> writes:
> On 24 Oct 2013, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> > > Lawrence, I would like to understand the kind of optimizations
> > > you have in mind that we would lose if signed integer arithmetic
> > > overflow is 'unspecified' as opposed to 'undefined behavior'.
> >
> > I seems to me that any flow analysis which propagate back
> > information assuming there is no overflow would not be possible
> > with unspecified behavior. If I'm right, undefined allows to
> > remove the if, unspecified doesn't.
> >
> > if (i == INT_MAX) {
> > // something
> > }
> > ++i
> >
> > Yours,
>
> Part of the complaints, and indeed the original motivation for
> this Study Group, is that people are unhappy with "arbitrary" code
> removal based on the fact that a construct invokes undefined
> behavior "down the road" when it hasn't been executed yet (but is
> on a must-execute path.)
>
> [ Note I wrote "abritrary" in quotes. ]

We generally expect compilers to remove redundant conditions. I
think the concern here is that the implicit precondition of the
increment operator is causing an explicit condition to be redundant.

While it is a bit daunting of a task, changing the definition of
builtin-operators to state their preconditions explicitly would
help to lessen the surprise at removing the explicit condition.

Of course, the compiler would be helpful if it warned that it was
removing a redundant condition in these circumstances.

> "unspecified behavior" means:
>
> behavior, for a well-formed program construct, correct data,
> that depends on the implementation [Note: The implementation
> is not required to document which behavior occurs. The range
> of possible behaviors is usually delineated by this
> International Standard. --end note ]
>
> In your example, you are correct that a compiler is permitted to
> remove the if-statement if i has the value INT_MAX. However, if
> i does not have the value INT_MAX, a conforming implementation
> cannot remove that if-statement.

Why not? The condition will never be true and the as-if rule
applies.

> My question is whether we would lose any useful
> transformations/optimizations (for programs we care about) that
> would be made much harder to apply if we required 'unspecified
> behavior'.

Well, in the example above, we have removed code, which at least
reduces memory use and consequently i-cache pressure.

> I suppose a subsidiary question is whether INT_MAX is considered
> 'correct data' for the operation "++i".

I say i == INT_MAX violates the operation's precondition.

-- 
Lawrence Crowl