[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Kenner
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Mon, 01 Jan 2007 20:51:40 EST

> No offense, but all enabling wrapv at O2 or less would do is cause
> more bug reports about
> 1. Getting different program behavior between O2 and O3
> 2. Missed optimizations at O2
> It also doesn't fit with what we have chosen to differentiate
> optimization levels based on.
> IMHO, it's just not the right solution to this problem.

I agree. I think -O1 or less would make more sense (though I wouldn't be in
favor of that either), but I agree that making that sort of a distinction
between -O2 and -O3 is a bad idea.

> VRP's optimizations are not generally useful in determining loop
> bounds (we have other code that does all the bound determination) or
> doing data dependence, so you would essentially lose no performance
> except in very weird cases.

The question that I'd like to understand the answer to is what kinds of
optimizations DO we get by having VRP optimized signed overflow.  Is it just
the elimination of tests on overflow?  If so, then it strikes me as
definitely wrong since those tests are probably there precisely to test for

It's somewhat analogous to the Ada issue with VRP a while ago: if I say that
a type T has a range of 10 to 20, I don't want VRP to delete a validity test
to see if a variable of that type has a valid value.  (It's a little more
complex in the Ada case since an out-of-range value is a "bounded error" in
Ada, not "undefined", but the issue is very similar.)

> But IMHO, we have to draw the line somewhere, and i'm fine with "if
> you want to test overflow, do it like this and we will guarantee it
> will work".

I think that's an interesting issue because there's no simple way of doing an
overflow test that doesn't assume wrapping semantics.

> Where there are reasonable positions on both sides, nobody ever
> accurately predicts what the majority of a hugely diverse population
> of language users is going to want, and almost everyone believes
> they are in that majority.

I agree.  That's why I support a middle-of-the-road position where we make
very few "guarantees", but do the best we can anyway to avoid gratuitously
(meaning without being sure we're gaining a lot of optimization) breaking
legacy code.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]