Patchwork [RFC] Add -fno-aggressive-loop-optimizations

login
register
mail settings
Submitter Richard Guenther
Date Jan. 31, 2013, 9:06 a.m.
Message ID <alpine.LNX.2.00.1301311005460.6889@zhemvz.fhfr.qr>
Download mbox | patch
Permalink /patch/217130/
State New
Headers show

Comments

Richard Guenther - Jan. 31, 2013, 9:06 a.m.
On Thu, 31 Jan 2013, Richard Biener wrote:

> On Wed, 30 Jan 2013, Pat Haugen wrote:
> 
> > On 01/29/2013 04:53 AM, Richard Biener wrote:
> > > I'm curious about the affect of -fno-aggressive-loop-optimizations
> > > on SPEC CPU 2006 numbers (not curious enough to try for myself
> > > though).  Both on extra PASSes for official latest sources
> > > (I have no access to those) and on performance.
> > The patch/option result in both 464.h264ref and 416.gamess passing (as opposed
> > to infinite loop). As for performance, I didn't see any difference outside of
> > noise range for both 32-bit and 64-bit runs on PowerPC.
> 
> Ok, I'll go ahead and apply the patch then.

Done.  I propose the following addition to changes.html.

Ok?

Thanks,
Richard.

2013-01-31  Richard Biener  <rguenther@suse.de>

	* changes.html: Mention -fno-aggressive-loop-optimizations.
Gerald Pfeifer - Feb. 16, 2013, 11:43 p.m.
On Thu, 31 Jan 2013, Richard Biener wrote:
> +<p>GCC now uses more a aggressive analysis to derive an upper bound for

I think "a " should be omitted here.

> +the number of iterations of loops using constraints imposed by language
> +standards.  This may cause non-conforming programs to no longer work as
> +expected, such as SPEC CPU 2006 464.h264ref and 416.gamess.  A new
> +option, <code>-fno-aggressive-loop-optimizations</code>, was added
> +to disable this aggressive analysis.</p>

Personally I would reduce aggressiveness and omit "aggressive" in
the last line above. :-)

Gerald
Richard Guenther - Feb. 18, 2013, 9:10 a.m.
On Sun, 17 Feb 2013, Gerald Pfeifer wrote:

> On Thu, 31 Jan 2013, Richard Biener wrote:
> > +<p>GCC now uses more a aggressive analysis to derive an upper bound for
> 
> I think "a " should be omitted here.

Yes, that was fixed before commit.

> > +the number of iterations of loops using constraints imposed by language
> > +standards.  This may cause non-conforming programs to no longer work as
> > +expected, such as SPEC CPU 2006 464.h264ref and 416.gamess.  A new
> > +option, <code>-fno-aggressive-loop-optimizations</code>, was added
> > +to disable this aggressive analysis.</p>
> 
> Personally I would reduce aggressiveness and omit "aggressive" in
> the last line above. :-)

Heh ... as you like ;)

Richard.

Patch

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.89
diff -u -r1.89 changes.html
--- changes.html	27 Jan 2013 13:44:12 -0000	1.89
+++ changes.html	31 Jan 2013 09:05:20 -0000
@@ -30,6 +30,13 @@ 
 <p>The G++ namespace association extension, <code>__attribute ((strong))</code>,
 has been deprecated. Inline namespaces should be used instead.</p>
 
+<p>GCC now uses more a aggressive analysis to derive an upper bound for
+the number of iterations of loops using constraints imposed by language
+standards.  This may cause non-conforming programs to no longer work as
+expected, such as SPEC CPU 2006 464.h264ref and 416.gamess.  A new
+option, <code>-fno-aggressive-loop-optimizations</code>, was added
+to disable this aggressive analysis.</p>
+
 <p>On ARM, a bug has been fixed in GCC's implementation of the AAPCS
 rules for the layout of vectors that could lead to wrong code being
 generated.  Vectors larger than 8 bytes in size are now by default