This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."


On 1/2/07, Mark Mitchell <mark@codesourcery.com> wrote:
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?

I can do this. What I also will do is improve VRP to still fold comparisons of the for a - 10 > 20 when it knows there is no overflow due to available range information for a (it doesn't do that right now). That might eliminate most of the bad effects of turning on -fwrapv for VRP. The question is if we want to assume wrapping semantics for signed ints in VRP then or if we just not want to assume anything if signed ints happen to wrap?

So, given 'a + 10' with a value range for a being [0, +INF], what should be
the resulting value range?  At the moment with -fno-wrapv we get [10, +INF],
with wrapping semantics we could get ~[-INF+10, 9] (which includes
the range we get with -fno-wrapv).

(I'll do this as I return from yet another short vacation - maybe someone can
beat me on producing the SPEC numbers, a s/flag_wrapv/1/ in VRP should
do it for all places that do not simply call into fold).

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]