From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22206 invoked by alias); 29 Jan 2004 07:08:49 -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 22185 invoked from network); 29 Jan 2004 07:08:48 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 29 Jan 2004 07:08:48 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.24) id 1Am6HT-0000i1-Ex for gcc@gnu.org; Thu, 29 Jan 2004 02:08:03 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Am6GU-0002HX-RF for gcc@gnu.org; Thu, 29 Jan 2004 02:07:33 -0500 Received: from [169.237.33.59] (helo=dante.ece.ucdavis.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Am6GU-0002HN-2a for gcc@gnu.org; Thu, 29 Jan 2004 02:07:02 -0500 Received: from dante.ece.ucdavis.edu (smmsp@localhost [127.0.0.1]) by dante.ece.ucdavis.edu (8.12.10/8.12.8) with ESMTP id i0T6lu4U005187; Wed, 28 Jan 2004 22:47:56 -0800 (PST) Received: from localhost (gshobaki@localhost) by dante.ece.ucdavis.edu (8.12.10/8.12.9/Submit) with ESMTP id i0T6bT0x005171; Wed, 28 Jan 2004 22:37:29 -0800 (PST) Date: Thu, 29 Jan 2004 10:14:00 -0000 From: Ghassan Shobaki To: Jan Hubicka cc: gcc-help@gcc.gnu.org, "Vladimir N. Makarov" , gcc@gnu.org, hubicka@ucw.cz Subject: Re: Superblock Instruction Scheduling in GCC 3.4 In-Reply-To: <20040128122317.GI8094@kam.mff.cuni.cz> Message-ID: 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 X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE 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/msg02171.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 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? Thanks -Ghassan On Wed, 28 Jan 2004, Jan Hubicka wrote: > > Hi, > > > > I am currently experimenting with superblock scheduling in a prerelease > > version (20040114) of gcc 3.4 on the spec2000 benchmarks. I have > > a few questions: > > > > The version that I have does not seem to accept the > > -fsched2-use-traces command line switch. So I went a head and set the > > following global variables in toplev.c in order to enforce superblock > > formation and scheduling: > > > > int flag_optimize = 1; > > int flag_schedule_insns = 1; > > int flag_schedule_insns_after_reload = 1; > > int flag_sched2_use_traces = 1; > > > > Q1. Is there a known bug in version 3.4 related to command-line options? > > Or I am doing something wrong? > > I jus ttested and -fsched2-use-traces seems to just work for me. What > kind of problems do you get? > > > > Q2. Should I set the following flag as well? > > int flag_branch_probabilities = ?; > > I tried it both ways and the superblocks generated when this flag is > > RESET are on average larger and have more branches in them (they are much > > harder to schedule), which does not make sense to me. What is superblock > > formation based on when branch probablities are not computed? It seems to > > me that setting this flag should be necessary! > > Yes, however it should be implied by -O2 flag. > You also may want the profile feedback. Without -fbranch-probabilities > you won't get any superblocks formed. > > > > Q3. Are there any other flags that I need to set in order to ensure > > proper superblock formation? > > I think -O2 -fsched2-use-traces shall do what you want. > > > > Q3. I have looked into the trace formation code in tracer.c and was > > confused about three different terms related to about the same > > concept : probability, count and frequency. Is there a documention that > > precisely defines each of these three terms and how they are used in > > trace formation? > > You may take a look at cfg.texi documentation I sent to mailing list > year or two ago, but it never went into official sources. > In general the count represent number of execution of given edge/block > when profile is read from feedback. It is 64bit number. > Each basic block has frequence that represent how commonly it is > executed relative to REG_FREQ_BASE. It is 32bit number and the most > frequent basic block is known to have REG_FREQ_BASE frequency at the > time profile was built, so it is easier to manipulate with when you > don't care about exactness and it is also available without profile > feedback based on guesses made by compiler. > Probablity is set for edges and represent probability that control flow > will leave basic block via that edge, again relative to REG_FREQ_BASE. > > Honza > > > > Thanks > > > > -Ghassan >