Re: [patch] Lno branch merge part 8 -- canonical induction variablecreation

[Roger Sayle <roger at eyesopen dot com>]

On Sat, 21 Aug 2004, Zdenek Dvorak wrote:
> > Fold certainly cares.
>
> isn't this wrong?  I mean, the fact that signed expressions do not
> overflow is C language specific, so using it with other frontends might
> cause problems.


I think the concept that you're trying to describe is GCC's "-fwrapv"
command line option and corresponding flag_wrapv variable.  This allows
the user and middle-end to assume that signed integer overflow is handled
as "expected" rather than being undefined as per the ISO C language
specifications.  The java front-end, for example, sets flag_wrapv by
default.

Many of the optimizations in the middle-end and RTL optimizers that
worry about overflow test for flag_wrapv and flag_trapv explicitly.
There are numerous optimizations (such as yours) that require flag_wrapv
and there are several that require !flag_wrapv.


As an example from "fold", the C/C++ language specifications allows the
compiler to optimize "(x * 4)/4" into "x", as overflow is undefined.
When assuming wrapping semantics, however, the top bits will be
clobbered.  Also check the use of !flag_wrapv in the old RTL loop
optimizers that use it to transform loops assuming bivs don't overflow.

The simplest fix is to add a test for "TYPE_UNSIGNED () || flag_wrapv"
to the problematic transformation in your code.

Perhaps one day, flag_wrapv might become the C and C++ default...

Roger
--