From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16741 invoked by alias); 9 Dec 2003 21:12:03 -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 16630 invoked from network); 9 Dec 2003 21:12:00 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 9 Dec 2003 21:12:00 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.24) id 1ATp8J-000854-My for gcc@gnu.org; Tue, 09 Dec 2003 16:11:03 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATq5v-0001y6-9z for gcc@gnu.org; Tue, 09 Dec 2003 17:13:10 -0500 Received: from [169.237.33.59] (helo=dante.ece.ucdavis.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATq5t-0001uK-GO for gcc@gnu.org; Tue, 09 Dec 2003 17:12:37 -0500 Received: from dante.ece.ucdavis.edu (gshobaki@localhost [127.0.0.1]) by dante.ece.ucdavis.edu (8.12.10/8.12.8) with ESMTP id hB9KrJi9006969; Tue, 9 Dec 2003 12:53:19 -0800 (PST) Received: from localhost (gshobaki@localhost) by dante.ece.ucdavis.edu (8.12.10/8.12.9/Submit) with ESMTP id hB9KrHwm006966; Tue, 9 Dec 2003 12:53:17 -0800 (PST) Date: Tue, 09 Dec 2003 21:45:00 -0000 From: Ghassan Shobaki To: Jan Hubicka cc: "Vladimir N. Makarov" , gcc-help@gcc.gnu.org, gcc@gnu.org Subject: Re: Superblock Instruction Scheduling in GCC In-Reply-To: <20031204000558.GD23084@atrey.karlin.mff.cuni.cz> Message-ID: References: <3FCDEE2C.19E04DE3@redhat.com> <20031204000558.GD23084@atrey.karlin.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: 2003-12/txt/msg00599.txt.bz2 I could not check out the integrated patch since the cvs server is currently down. On the other hand, when I tried to add the patch (as published on the web) manually on top of release 3.3.1 the resulting binary failed. I am not sure if I did something wrong or just needed to do that on top of a more recent version of the gcc code. So, I am kind of stuck at this point. Do you have any source files that I can add on top of release 3.3.1 or 3.3.2 to enable superblock scheduling? Thanks -Ghassan On Thu, 4 Dec 2003, Jan Hubicka wrote: > > Ghassan Shobaki wrote: > > > > > I know how to get gcc to form superblocks (by using the -ftracer > > > command-line switch), but is there a way to get it to use these > > > superblocks as scheduling regions in the instruction scheduling pass? > > > Currently, the instruction scheduling module forms regions that are totally > > > different from the superblocks that are formed in the tracer module > > > even though each superblock is a valid scheduling region. > > > Any idea how I can achieve this? Or are there any plans to do superblock > > > instruction scheduling in the near future? > > > > There was Jan Hubicka's patch for this. Please look at it > > > > http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00499.html > > > > This patch should work for all platforms except for IA64 whose the second > > scheduling is made on EBB. > > This patch is currently in the mainline tree, so you can simply use > -fsched2-use-traces / -fsched2-use-superblocks > > > > I tried trace scheduling for IA64 (but I did not post the patch for ia64). > > Here the results are > > > > http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00499.html > > > > The problem with trace scheduling is that the generated code is bigger, the > > compiler is slower and the code improvement is insignificant. > > > > If you manage to achieve an improvement for a platform on a credible > > benchmark (SPEC95, SPEC2000), we could consider to add the patch to gcc at > > least for given platform for -O3. Because the compiler changed since the > > patch was posted, there is a probability that you could achieve this. > > Yes, we need experimenting here. > I was quite surprised that the benefits wasn't too noticeable on > in-order architecture and I would like to hear about any results > (positive or negative). > -fsched2-use-superblocks should bring most of benefits at no code size > costs, while -fsched2-use-traces is more experimental and probably needs > profile feedback to do somethign usefull. (I managed to get some > speedups using this on Athlon but the benefits wasn't considerable > enought to discuss inclusion in -O3 -fbranch-probabilities combination) > > Honza > > > > > > Vlad > > >