headers
Daniel Berlin | 1 Jan 2007 01:13

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

On 12/31/06, Richard Guenther <richard.guenther <at> gmail.com> wrote:
> On 12/31/06, Daniel Berlin <dberlin <at> dberlin.org> wrote:
> > On 12/31/06, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> > > "Steven Bosscher" <stevenb.gcc <at> gmail.com> writes:
> > >
> > > > On 12/31/06, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> > > >> Also, as I understand it this change shouldn't affect gcc's
> > > >> SPEC benchmark scores, since they're typically done with -O3
> > > >> or better.
> > > >
> > > > It's not all about benchmark scores.
> > >
> > > But so far, benchmark scores are the only scores given by the people
> > > who oppose having -O2 imply -fwrapv.  If the benchmarks use -O3 they
> > > wouldn't be affected by such a change -- and if so, we have zero hard
> > > evidence of any real harm being caused by having -O2 imply -fwrapv.
> > >
> > > > I think most users compile at -O2
> > >
> > > Yes, which is why there's so much argument about what -O2 should do....
> > >
> > > > You say you doubt it affects performance.  Based on what?  Facts
> > > > please, not guesses and hand-waiving...
> > >
> > > The burden of proof ought to be on the guys proposing -O2
> > > optimizations that break longstanding code, not on the skeptics.
> >
> > The burden ought to be (and IMHO is) on those who propose we change
> > optimizer behavior in order to support something non-standard.
> >
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel Berlin | 1 Jan 2007 01:17

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

On 12/31/06, Bruce Korb <bkorb <at> gnu.org> wrote:
> Daniel Berlin wrote:
> >> Admittedly it's only two small tests, and it's with 4.1.1.  But that's
> >> two more tests than the -fwrapv naysayers have done, on
> >> bread-and-butter applications like coreutils or gzip or Emacs (or GCC
> >> itself, for that matter).
> >
> > These are not performance needing applications.
> > I'll happily grant you that  adding -fwrapv will make no difference at
> > all on any application that does not demand performance in integer or
> > floating point calculations.
>
> It seems then that this pretty-much ought to settle it:
> If the only folks that would really care are those that do performance
> critical work, then 99.9% of folks not doing that kind of work should
> not bear the risk of having their code break.  The long standing
> presumption, standardized or not, is that of wrapv semantics.
> Changing that presumption without multiple years of -Wall warnings
> is a Really, Really, Really Bad Idea.
>

I generally have no problem with turning on -fwrapv at O2, but i'm
curious where this ends.
After all, strict aliasing makes it hard to write a bunch of styles of
code people really want to write, and breaks real world programs and
GNU software.

Yet we decided to keep it on at O2, and off at O1.

We assume array accesses outside the defined length of an array are
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vincent Lefevre | 1 Jan 2007 02:04

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

On 2006-12-31 11:37:21 -0500, Richard Kenner wrote:
> Certainly.  Indeed I think that's the whole point of this thread: that if
> you want to catch ALL potential optimizations opportunities given to you
> by the standard, you must assume that signed overflows are undefined.
> 
> However, what's being discussed is an engineering tradeoff where you give
> up SOME optimization opportunities to avoid breaking code.

I was responding to a particular point. You said a few messages ago:

| I can't speak for any other GCC developer, but I personally am quite
| comfortable viewing any code that assumes wrapping semantics as broken
| and needing fixing with the exception of these cases of checking for
| overflow: there simply is no good way in C to do these checks in a portable
| manner and, as I said, I think we should make sure they continue to work
| and maybe even document that.

Now:

> Essentially, there are three choices: with -fwrapv, you must preseve
> wrapping semantics and do NONE of those optimizations; with
> -fno-wrapv, you can do ALL of them; in the default cause, a
> heuristic can be used that attempts to balance optimization quality
> against breakage of old code.

This isn't just about old code. If you're saying that old code with
overflow checking can't be fixed (in a portable manner...), then new
code will probably use the same tricks. Then hoping that such code
will continue to work is not sufficient. You need to really make sure
that it will still work. This means that either "overflow checking"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Eggert | 1 Jan 2007 02:21
Favicon

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

"Daniel Berlin" <dberlin <at> dberlin.org> writes:

>> 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
>>
> Note the distinct drop in performance across almost all the benchmarks
> on Dec 30, including popular programs like bzip2 and gzip.

That benchmark isn't that relevant, as it's using -O3, as is typical
for SPEC benchmarks.

This discussion is talking about -O2, not -O3.  The proposed change
(i.e., having -O2 imply -fwrapv) would not affect -O3 benchmark
scores.
Permalink | Reply | 1 comment |
headers
Paul Eggert | 1 Jan 2007 02:32
Favicon

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

Robert Dewar <dewar <at> adacore.com> writes:

> We have not seen ONE imaginary example, let
> alone a real example, where the optimziation of loop invariants
> (by far the most important optimization in the class we are
> discussing) would break existing code.

But didn't this thread get started by a real program that was broken
by an optimization of loop invariants?  Certainly I got a real bug
report of a real problem, which you can see here:

http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00084.html

Here is a bit more discussion:

http://gcc.gnu.org/ml/gcc/2006-12/msg00607.html

If this doesn't count as "optimization of loop invariants"
then what would count?

This particular example was just a test program run by "configure", so
the penalty for getting it wrong wasn't that severe -- the application
compiled its own version of mktime rather than using the system
mktime.  But I daresay I can find an example of real-world production
code that does something similar.
Permalink | Reply | 3 comments |
headers
Ian Lance Taylor | 1 Jan 2007 02:34
Picon
Favicon
Gravatar

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

kenner <at> vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> > Note that -fwrapv also _enables_ some transformations on signed
> > integers that are disabled otherwise.  We for example constant fold
> > -CST for -fwrapv while we do not if signed overflow is undefined.
> > Would you change those?
> 
> I don't understand the rationale for not wrapping constant folding when
> signed overflow is undefined: what's the harm in "defining" it as wrapping
> for that purpose?  If it's undefined, then why does it matter what we
> fold it to?  So we might as well fold it to what traditional code expects.

If flag_wrapv is false, we can't do any optimization which may
introduce signed overflow when it did not already exist.  If we do,
future optimization passes may take advantage of the undefined signed
overflow to break the code unjustifiably.  The problem is that we
don't have a way to annotate particular tree or RTL nodes as using
wrapping arithmetic.  (This is something we will have to change for
LTO.)

Ian
Permalink | Reply | 1 comment |
headers
Richard Kenner | 1 Jan 2007 02:54
Picon

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

> This isn't just about old code. If you're saying that old code with
> overflow checking can't be fixed (in a portable manner...), then new
> code will probably use the same tricks. 

I said there's no "good" way, meaning as compact as the current tests.  But
it's certainly easy to test for overflow in a correct and portable manner
that's not TOO inefficient.  I haven't tested it, but this ought to do it and
is only 9 instructions on x86-64:

/* Return 1 IFF a + b will overflow as signed numbers.  Assumes two's
   complement.  */

bool
overflow (int a, int b)
{
  unsigned int pos_a, pos_b;

  /* If they have different signs, their sum can't overflow.  */
  if ((a ^ b) < 0)
    return false;

  /* Otherwise, sum the non-sign bits as unsigned (this is close to abs,
     but avoids overflow for INT_MIN) and see if that, interpreted as a
     signed number, would be negative.  If so, the sum will overflow.  */
  pos_a = (a & ((1u << (sizeof (int) * HOST_BITS_PER_CHAR - 1)) - 1));
  pos_b = (b & ((1u << (sizeof (int) * HOST_BITS_PER_CHAR - 1)) - 1));
  return (pos_a + pos_b) >> (sizeof (int) * HOST_BITS_PER_CHAR - 1);
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Seongbae Park | 1 Jan 2007 02:54
Picon

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

On 12/31/06, Daniel Berlin <dberlin <at> dberlin.org> wrote:
...
> > I added -fwrapv to the Dec30 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
>
> Note the distinct drop in performance across almost all the benchmarks
> on Dec 30, including popular programs like bzip2 and gzip.

Also, this is only on x86 -
other targets that benefit more from software pipelinine/modulo scheduling
may suffer even more than x86, especially on the FP side.
--

-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"
Permalink | Reply | 0 comments |
headers
Richard Kenner | 1 Jan 2007 02:59
Picon

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

> http://gcc.gnu.org/ml/gcc/2006-12/msg00607.html
> 
> If this doesn't count as "optimization of loop invariants"
> then what would count?

One where the induction variable was updated additively, not
multiplicatively.  When we talk about normal loop optimizations,
that's what we mean.  I agree that the optimization in this case is of
questionable value.
Permalink | Reply | 0 comments |
headers
Richard Kenner | 1 Jan 2007 03:02
Picon

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

> > > Note that -fwrapv also _enables_ some transformations on signed
> > > integers that are disabled otherwise.  We for example constant fold
> > > -CST for -fwrapv while we do not if signed overflow is undefined.
> > > Would you change those?
> > 
> > I don't understand the rationale for not wrapping constant folding when
> > signed overflow is undefined: what's the harm in "defining" it as wrapping
> > for that purpose?  If it's undefined, then why does it matter what we
> > fold it to?  So we might as well fold it to what traditional code expects.
> 
> If flag_wrapv is false, we can't do any optimization which may
> introduce signed overflow when it did not already exist.  

But how would that happen here?  If we constant-fold something that would
have overflowed by wrapping, we are ELIMINATING a signed overflow, not
INTRODUCING one.  Or do I misunderstand what folding we're talking about here?
Permalink | Reply | 1 comment |

Gmane