From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2242 invoked by alias); 27 Jul 2011 06:47:44 -0000 Received: (qmail 2231 invoked by uid 22791); 27 Jul 2011 06:47:43 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Jul 2011 06:47:27 +0000 Received: by wwj26 with SMTP id 26so961473wwj.8 for ; Tue, 26 Jul 2011 23:47:26 -0700 (PDT) Received: by 10.216.61.79 with SMTP id v57mr2402142wec.6.1311749245714; Tue, 26 Jul 2011 23:47:25 -0700 (PDT) Received: from yakj.usersys.redhat.com (93-34-199-31.ip51.fastwebnet.it [93.34.199.31]) by mx.google.com with ESMTPS id k84sm817174weq.46.2011.07.26.23.47.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 23:47:24 -0700 (PDT) Message-ID: <4E2FB47B.5090702@gnu.org> Date: Wed, 27 Jul 2011 08:12:00 -0000 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Xinliang David Li CC: Joern Rennecke , Richard Henderson , "gcc@gcc.gnu.org" , Laszlo Ersek Subject: Re: [RFC] Remove -freorder-blocks-and-partition References: <4E25F810.6050904@redhat.com> <4E2D4425.9040104@gnu.org> <20110725213048.j08lao8lc0wcs4s4-nzlynne@webmail.spamcop.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00471.txt.bz2 On 07/27/2011 06:51 AM, Xinliang David Li wrote: > > If we could retain most of the speedups when the optimization works well > > but avoid most of the slowdown in the benchmarks that are currently hurt, > > we could improve the overall SPEC06 score. And hopefully, this would > > also be beneficial to other code. > > Agree. There are certainly problems in the partition pass, as for > bzip2 the icache misses actually go up with partition, which is not > expected. It needs further analysis. It's probably too aggressive. Icache misses go up because a) the overall size of the executable grows; b) cold parts are probably not cold enough in the case of bzip2.f Paolo