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

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

[Richard Biener]

The following patch adds -faggressive-loop-optimizations, enabled by
default, guarding the use of language constraints for number of
iteration analysis.  Starting with GCC 4.8 we more aggressively
make use of iteration bounds derived from those constraints
which for example breaks SPEC CPU 2006 464.h264ref which is
not C99 conforming but SPEC folks think it is not in the spirit
of theirs to fix such issues (but we compiler folks have to deal
with that - where the language standard interpretation would
be to DWIM, thus let SPEC pass).

Thus, GCC 4.8 will need -fno-aggressive-loop-optimizations in
base flags to compile official SPEC CPU 2006 sources (as opposed
to local patched ones).  I suppose I'll add a sentence to
changes.html reflecting that fact.

Note that using this flag will disable using of language constraints
of this kind from number-of-iteration analysis completely
(mind, that's not previous behavior - previous behavior just used
the resulting information in less places).  It places it in the
same ballpark as -fno-strict-aliasing and -fno-strict-overflow.
Thus, no guarantees - it does not make out-of-bound array accesses
in any way more valid - your broken code may still be optimized
in unexpected ways.  It just disables one source of "unexpectedness".
No testcase added for that reason.

Thus, any objections to providing this switch guarding an
implementation detail of number of iteration analysis?

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.

Thanks,
Richard.

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

	PR middle-end/53073
	* common.opt (faggressive-loop-optimizations): New flag,
	enabled by default.
	* doc/invoke.texi (faggressive-loop-optimizations): Document.
	* tree-ssa-loop-niter.c (estimate_numbers_of_iterations_loop): Guard
	infer_loop_bounds_from_undefined by it.

Index: gcc/common.opt
===================================================================
*** gcc/common.opt	(revision 195530)
--- gcc/common.opt	(working copy)
*************** Driver Undocumented
*** 792,797 ****
--- 792,801 ----
  fabi-version=
  Common Joined RejectNegative UInteger Var(flag_abi_version) Init(2)
  
+ faggressive-loop-optimizations
+ Common Report Var(flag_aggressive_loop_optimizations) Optimization Init(1) 
+ Aggressively optimize loops using language constraints
+ 
  falign-functions
  Common Report Var(align_functions,0) Optimization UInteger
  Align the start of functions
Index: gcc/doc/invoke.texi
===================================================================
*** gcc/doc/invoke.texi	(revision 195530)
--- gcc/doc/invoke.texi	(working copy)
*************** Objective-C and Objective-C++ Dialects}.
*** 349,355 ****
  
  @item Optimization Options
  @xref{Optimize Options,,Options that Control Optimization}.
! @gccoptlist{-falign-functions[=@var{n}] -falign-jumps[=@var{n}] @gol
  -falign-labels[=@var{n}] -falign-loops[=@var{n}] @gol
  -fassociative-math -fauto-inc-dec -fbranch-probabilities @gol
  -fbranch-target-load-optimize -fbranch-target-load-optimize2 @gol
--- 349,356 ----
  
  @item Optimization Options
  @xref{Optimize Options,,Options that Control Optimization}.
! @gccoptlist{-faggressive-loop-optimizations -falign-functions[=@var{n}] @gol
! -falign-jumps[=@var{n}] @gol
  -falign-labels[=@var{n}] -falign-loops[=@var{n}] @gol
  -fassociative-math -fauto-inc-dec -fbranch-probabilities @gol
  -fbranch-target-load-optimize -fbranch-target-load-optimize2 @gol
*************** When @option{-fgcse-after-reload} is ena
*** 6988,6993 ****
--- 6989,7004 ----
  pass is performed after reload.  The purpose of this pass is to clean up
  redundant spilling.
  
+ @item -faggressive-loop-optimizations
+ @opindex faggressive-loop-optimizations
+ This option tells the loop optimizer to use language constraints to
+ derive bounds for the number of iterations of a loop.  This assumes that
+ loop code does not invoke undefined behavior by for example causing signed
+ integer overflows or out-of-bound array accesses.  The bounds for the
+ number of iterations of a loop are used to guide loop unrolling and peeling
+ and loop exit test optimizations.
+ This option is enabled by default.
+ 
  @item -funsafe-loop-optimizations
  @opindex funsafe-loop-optimizations
  This option tells the loop optimizer to assume that loop indices do not
Index: gcc/tree-ssa-loop-niter.c
===================================================================
*** gcc/tree-ssa-loop-niter.c	(revision 195530)
--- gcc/tree-ssa-loop-niter.c	(working copy)
*************** estimate_numbers_of_iterations_loop (str
*** 3336,3342 ****
      }
    exits.release ();
  
!   infer_loop_bounds_from_undefined (loop);
  
    discover_iteration_bound_by_body_walk (loop);
  
--- 3336,3343 ----
      }
    exits.release ();
  
!   if (flag_aggressive_loop_optimizations)
!     infer_loop_bounds_from_undefined (loop);
  
    discover_iteration_bound_by_body_walk (loop);
  

Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations

[Pat Haugen]

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.

-Pat

Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations

[Richard Biener]

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.

Richard.

Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations

[Richard Biener]

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.

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

Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations

[Gerald Pfeifer]

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

Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations

[Richard Biener]

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.

Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations

[Dominique Dhumieres]

I just finished a clean bootstrap of r195576 with your patch.
I have used it to clean the XPASS of gfortran.dg/do_1.f90 for -O0
and -O1 with the following patch:

--- /opt/gcc/_clean/gcc/testsuite/gfortran.dg/do_1.f90	2012-10-18 20:35:25.000000000 +0200
+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/do_1.f90	2013-01-30 17:00:30.000000000 +0100
@@ -1,4 +1,5 @@
-! { dg-do run { xfail *-*-* } }
+! { dg-do run }
+! { dg-additional-options "-fno-aggressive-loop-optimizations" }
 ! XFAIL is tracked in PR 54932
 ! Program to check corner cases for DO statements.
 program do_1

Cheers,

Dominique