From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3204 invoked by alias); 29 Jan 2013 10:53:10 -0000 Received: (qmail 3196 invoked by uid 22791); 29 Jan 2013 10:53:09 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Jan 2013 10:53:01 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id A9ED7A52B1; Tue, 29 Jan 2013 11:53:00 +0100 (CET) Date: Tue, 29 Jan 2013 10:53:00 -0000 From: Richard Biener To: gcc-patches@gcc.gnu.org Cc: Jakub Jelinek , hjl.tools@gmail.com Subject: [PATCH][RFC] Add -fno-aggressive-loop-optimizations Message-ID: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg01364.txt.bz2 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 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);