From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16548 invoked by alias); 3 Feb 2009 14:48:21 -0000 Received: (qmail 16518 invoked by uid 48); 3 Feb 2009 14:48:10 -0000 Date: Tue, 03 Feb 2009 14:48:00 -0000 Message-ID: <20090203144810.16517.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/37534] [4.4 Regression] IRA causes 17% degradation in 187.facerec benchmark In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "vmakarov at redhat 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: 2009-02/txt/msg00209.txt.bz2 ------- Comment #11 from vmakarov at redhat dot com 2009-02-03 14:48 ------- I have a patch (a new spill heuristic) which makes facerec even faster with IRA on power6. The patch is in http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00368.html Unfortunately the new spill heuristic results in worse SPECINT2000 scores for x86, x86_64. So I did not committed the patch. Facerec has one very hot (80%) function localmove::graphRoutines.f90 and there is only one hot loop in the function. Although the loop is pretty big because of inlining TopCostFct. The loop contains a few if-statements and several big switch-statements. But only a small part of the loop body is hot. Static branch prediction makes very inaccurate results in this case and the old RA accidentally generates a better code than IRA. This is classical example of heuristic approach drawback. You never get best code using one heuristic for all programs. Sometimes the old RA will generate better code especially when the static branch probability prediction is bad. What are goal should be is to achieve better or not worse code in "average", i.e. for some credible benchmark like SPECFP2000 and IRA is successful in this. I am still working on some better spill heuristics. Classical graph coloring spill heuristics are bad and IMHO they should be based on register pressure not on number of allocnos conflicting with allocno being spilled. I don't think the problem will be solved for gcc4.4 but it might be solved for gcc 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534