From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11450 invoked by alias); 7 Dec 2012 09:05:14 -0000 Received: (qmail 11434 invoked by uid 22791); 7 Dec 2012 09:05:13 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Dec 2012 09:05:08 +0000 Received: by mail-we0-f175.google.com with SMTP id z53so102677wey.20 for ; Fri, 07 Dec 2012 01:05:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.93.3 with SMTP id cq3mr1582975wib.1.1354871106794; Fri, 07 Dec 2012 01:05:06 -0800 (PST) Received: by 10.194.179.130 with HTTP; Fri, 7 Dec 2012 01:05:06 -0800 (PST) In-Reply-To: <20121206214313.GG671@atrey.karlin.mff.cuni.cz> References: <50C0FCDE.5010508@linux.vnet.ibm.com> <20121206214313.GG671@atrey.karlin.mff.cuni.cz> Date: Fri, 07 Dec 2012 09:05:00 -0000 Message-ID: Subject: Re: [PATCH, rs6000] Update default loop peel limits From: Richard Biener To: Jan Hubicka Cc: Pat Haugen , GCC Patches , David Edelsohn Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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: 2012-12/txt/msg00459.txt.bz2 On Thu, Dec 6, 2012 at 10:43 PM, Jan Hubicka wrote: >> The following patch restores the old default limits for loop peeling >> that were recently changed to 100 and caused a 20% degradation in >> 454.calculix. >> >> Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk? >> >> -Pat >> >> >> 2012-12-06 Pat Haugen >> * config/rs6000/rs6000.c (rs6000_option_override_internal): Set >> default loop peeling limits. > > Actually the calculix regression is also seen on core. > Igor was looking into what loops got slower and why. Either we can fix that partiuclar > loop or revert to the old default (that sadly causes quite a lot of code bloat) Well, as the patch regressed the testcase in put in the testsuite for calculix that is no surprise... gfortran.dg/reassoc_4.f. The fix for the testcase was to increase the limit with a --param :/ Note that it is even beneficial to unroll two more levels of the nest completely. It's just an insane testcase (and I spent quite some time on it trying to somehow autodetect the simplification opportunities - see the unrolling heuristic rewrite patch I dumped on you a few weeks ago). No advice from me on how to "fix" this ... but eventually the rewrite restores the old behavior with the new limits (I did the rewrite to try to somehow make it do two extra levels of nest unrolling ...). Richard. > Honza