[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: Vincent Lefevre
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Sun, 31 Dec 2006 15:03:32 +0100
User-agent: Mutt/1.5.13-vl-r14963 (2006-12-20)

On 2006-12-31 08:06:56 -0500, Robert Dewar wrote:
> Vincent Lefevre wrote:
> >On 2006-12-30 20:07:09 -0500, Robert Dewar wrote:
> >> In my view, this comparison optimization should not have been put in
> >> without justification given that it clearly does affect the semantics
> >> of real code. Indeed if you really see code like
> >>
> >>   if (a - 10 < 20)
> >>
> >> in place of
> >>
> >>   if (a < 30)
> >>
> >> a very likely explanation is that you are deliberately doing something
> >> strange with wrap around, and should leave it alone.
> >
> >I disagree concerning your "very likely explanation". This code
> >may come from the use of macros, in which case this has nothing
> >to do with wrap around.
> Sorry, my "you" was unclear, I meant you as in a human not you as
> in a compiler. Yes, if the code comes from macros, it might well
> be in advertent, and of course inadvertent overflow, never mind
> potential overflow can be hidden in macros this way.

This is still not clear. If I write a - 10 < 20 (where a is signed),
this implicitly assumes that a - 10 cannot overflow; in particular,
when writing macros, I take care of that. So, from this point of
view, the optimization is safe as long as -ftrav is not used.

> My point was that if you see this in a source program, it is in
> fact a possible candidiate for code that can be destroyed by
> the optimization.

Well, only for non-portable code (i.e. code based on wrap). I also
suppose that this kind of code is used only to check for overflows.

> And that's the trouble, this is an optimization which does improve
> performance, but may destroy existing code, and the very example
> you gave to talk about improved performance is also a nice case
> of showing why it may destroy performance. In fact the wrap
> around range test is a standard idiom for "hand optimization"
> of range tests.

Yes, and the lack of optimization would be even worse.

Vincent Lefèvre <address@hidden> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

reply via email to

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