From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21546 invoked by alias); 9 Feb 2009 16:18:29 -0000 Received: (qmail 21485 invoked by uid 48); 9 Feb 2009 16:18:17 -0000 Date: Mon, 09 Feb 2009 16:18:00 -0000 Subject: [Bug tree-optimization/39141] New: overzealous unrolling (peeling) destroys code locality X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "amylaar at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-02/txt/msg00788.txt.bz2 I see a 50% cycle increase for EEMBC idctrn01 going from gcc 4.2.1 to gcc 4.4 . There are two issues, overzealous unrolling, and constant propagation in the unrolled loops. While both issues can be avoided by reducing the parameter "max-completely-peeled-insns" to 200, this is not really satisfactory, since that is a rather fragile parameter setting and is not really related to the problem, and it holds other code back, like EEMBC viterb00 benchmark, which looses 5% performance with that setting. There are a number of loops which are completely unrolled, thus pushing their containing loop size above the size of the instruction cache. There is no point in doing such unrolling, since it is more expensive to fill the instruction cache with an unrolled loop than to execute a rolled loop. I have implemented a heuristic to estimate the size of the outer loop (or function in absence of an outer loop) assuming that its inner loops will be unrolled in accordance with PARAM_MAX_UNROLL_TIMES, PARAM_MAX_UNROLLED_INSNS and PARAM_MAX_COMPLETELY_PEEL_TIMES, and if that size exceeds a threshold (a new parameter), complete unrolling is inhibited. This change has reduced the idctrn01 regression to 13.7% while leaving the other EEMBC benchmarks alone. I expect that I can address the remaining performance regression by inhibiting inappropriate constant propagation - there are 798 addresses of the form absolute address+offset in the main benchmark assembly file, each of which translates into one instruction word too many, in total 20% of the text size of that module. I can post the unroller heuristic patch as soon as we have the confirmation from the FSF that they have filed the Copyright Assignment we gave them last year. -- Summary: overzealous unrolling (peeling) destroys code locality Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39141