Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations
On Sun, 17 Feb 2013, Gerald Pfeifer wrote: On Thu, 31 Jan 2013, Richard Biener wrote: +pGCC 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
On Thu, 31 Jan 2013, Richard Biener wrote: +pGCC 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
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
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 rguent...@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.html27 Jan 2013 13:44:12 - 1.89 +++ changes.html31 Jan 2013 09:05:20 - @@ -30,6 +30,13 @@ pThe G++ namespace association extension, code__attribute ((strong))/code, has been deprecated. Inline namespaces should be used instead./p +pGCC 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 + pOn 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
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.0 +0200
+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/do_1.f902013-01-30
17:00:30.0 +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
Re: [PATCH][RFC] Add -fno-aggressive-loop-optimizations
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
[PATCH][RFC] Add -fno-aggressive-loop-optimizations
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 rguent...@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
}
