Daniel Berlin wrote:
>> Richard Guenther added -fwrapv to the December 30 run of SPEC at
>> <http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html>
>> and
>> <http://www.suse.de/~gcctest/SPEC/CINT/sb-vangelis-head-64/recent.html>.
>> Daniel Berlin and Geert Bosch disagreed about how to interpret
>> these results; see <http://gcc.gnu.org/ml/gcc/2007-01/msg00034.html>.
Thank you for pointing that out. I apologize for having missed it
previously.
As others have noted, one disturbing aspect of that data is that it
shows that there is sometimes an inverse correlation between the base
and peak flags. On the FP benchmarks, the results are mostly negative
for both base and peak (with 168.wupwise the notable exception); on the
integer benchmarks it's more mixed. It would be nice to have data for
some other architectures: anyone have data for ARM/Itanium/MIPS/PowerPC?
So, my feeling is similar to what Daniel expresses below, and what I
think Ian has also said: let's disable the assumption about signed
overflow not wrapping for VRP, but leave it in place for loop analysis.
Especially given:
>> We don't have an exhaustive survey, but of the few samples I've
>> sent in most of code is in explicit overflow tests. However, this
>> could be an artifact of the way I searched for wrapv-dependence
>> (basically, I grep for "overflow" in the source code). The
>> remaining code depended on -INT_MIN evaluating to INT_MIN. The
>> troublesome case that started this thread was an explicit overflow
>> test that also acted as a loop bound (which is partly what caused
>> the problem).
it sounds like that would eliminate most of the problem. Certainly,
making -INT_MIN evaluate to INT_MIN, when expressed like that, is an
easy thing to do; that's just a guarantee about constant folding.
There's no reason for us not to document that signed arithmetic wraps
when folding constants, since we're going to fold the constant to
*something*, and we may as well pick that answer.
I don't even necessarily think we need to change our user documentation.
We can just choose to make the compiler not make this assumption for
VRP, and to implement folding as two's-complement arithmetic, and go on
with life. In practice, we probably won't "miscompile" many
non-conforming programs, and we probably won't miss two many useful
optimization opportunities.
Perhaps Richard G. would be so kind as to turn this off in VRP, and
rerun SPEC with that change?