From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6431 invoked by alias); 29 Jan 2004 10:14:23 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6384 invoked from network); 29 Jan 2004 10:14:20 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 29 Jan 2004 10:14:20 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.24) id 1Am9B0-0002gr-PV for gcc@gnu.org; Thu, 29 Jan 2004 05:13:34 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Am9BD-0002pE-OT for gcc@gnu.org; Thu, 29 Jan 2004 05:14:18 -0500 Received: from [195.113.31.123] (helo=atrey.karlin.mff.cuni.cz) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Am9BD-0002oy-4J for gcc@gnu.org; Thu, 29 Jan 2004 05:13:47 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 3CD0A4C0048; Thu, 29 Jan 2004 11:12:03 +0100 (CET) Date: Thu, 29 Jan 2004 11:15:00 -0000 From: Jan Hubicka To: Ghassan Shobaki Cc: Jan Hubicka , gcc-help@gcc.gnu.org, "Vladimir N. Makarov" , gcc@gnu.org, hubicka@ucw.cz Subject: Re: Superblock Instruction Scheduling in GCC 3.4 Message-ID: <20040129101203.GB30883@atrey.karlin.mff.cuni.cz> References: <3FCDEE2C.19E04DE3@redhat.com> <20031204000558.GD23084@atrey.karlin.mff.cuni.cz> <20040128122317.GI8094@kam.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-SW-Source: 2004-01/txt/msg02172.txt.bz2 > > Ok, I have just verified that gcc DOES accept the -fsched2-use-tracer and > invoke the ebb scheduler as expected. However, it does not set the > flag_branch_probabilities automatically. It only sets it when I > explicitly use the -fbranch-probabilities command-line switch. Here are > the two cases that I have tried: > > g++ -O3 -fsched2-use-traces > Generates ~151K superblocks on my benchmark suite with lots of large > superblocks that include 10 basic blocks or more > > g++ -O3 -fsched2-use-traces -fbranch-probabilities > Generates only ~123K superblocks on my benchmark suite with the vast > majority of superblocks consisting of less than 10 basic blocks -fbranch-probabilities can be accpeted only when program has been earlier profiled. GCC does have logic for statically guessing the branch outcomes when these are not available (-fguess-branch-probability) so the superblocks can be built, just they are inferrior to those built with feedback available. > > So, the question is: Why did the compiler generate more superblocks > when branch probabilities were not computed? Do the superblocks generated > in that case make any sense? > And the bottom line question for me is: which setting should I use in my > research on superblocks? It is always better to use the profile, so I would recommend you -fbranch-probabilities unless you are interested in experiments with static prediction algorithms. Honza