From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2197 invoked by alias); 18 Jun 2010 07:51:30 -0000 Received: (qmail 2108 invoked by uid 48); 18 Jun 2010 07:51:06 -0000 Date: Fri, 18 Jun 2010 07:51:00 -0000 Subject: [Bug middle-end/44576] New: testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching+peeling X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "borntraeger at de dot ibm dot com" 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: 2010-06/txt/msg01831.txt.bz2 testsuite/gfortran.dg/zero_sized_1.f90 takes almost 11 minutes to compile on my notebook when combining aggressive loop prefetching with loop peeling: $ time gfortran-4.5 -O3 -march=core2 zero_sized_1.f90 -S -fprefetch-loop-arrays -funroll-loops --param max-completely-peeled-insns=2000 real 10m54.594s user 10m48.638s sys 0m0.393s The compiler is almost always in compute_miss_rate introduced by http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00641.html The problem is triggered by several things: - loop peeling creates thousands of references (with only a small delta) and each reference is compared with every other reference - for each comparison we iterate over all alignments - for each alignment we iterate over all distinct iterators As you can see this causes an exploding complexitiy. Furthermore,since the cache line size is passed in via an external variable, the compiler cannot optimize the integer division into shifts. I think the right solution would be to reduce the complexity of compute_miss_rate, but I have not found a good solution yet. -- Summary: testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching+peeling Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: borntraeger at de dot ibm dot com GCC host triplet: several, i486, s390.. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576