From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15661 invoked by alias); 3 Jun 2008 22:03:35 -0000 Received: (qmail 15649 invoked by uid 22791); 3 Jun 2008 22:03:32 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Jun 2008 22:03:15 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m53M3DVY008327; Tue, 3 Jun 2008 18:03:13 -0400 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m53M3CwR015201; Tue, 3 Jun 2008 18:03:12 -0400 Received: from toll.yyz.redhat.com (toll.yyz.redhat.com [10.15.16.165]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m53M3C19027884; Tue, 3 Jun 2008 18:03:12 -0400 Message-ID: <4845BF9F.9000509@redhat.com> Date: Tue, 03 Jun 2008 22:03:00 -0000 From: Vladimir Makarov User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Andrey Belevantsev CC: GCC Patches , Jim Wilson Subject: Re: [RFC] Selective scheduling pass References: <4845522C.3010006@ispras.ru> In-Reply-To: <4845522C.3010006@ispras.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg00150.txt.bz2 Andrey Belevantsev wrote: > Hello, > > The patches in this thread introduce selective scheduler in GCC, > implemented by myself, Dmitry Melnik, Dmitry Zhurikhin, Alexander > Monakov, and Maxim Kuvyrkov while he was at ISP RAS. Selective > scheduler is aimed at scheduling eager targets such as ia64, power6, > and cell. The implementation contains both the scheduler and the > software pipeliner, which can be used on loops with control flow not > handled by SMS. The scheduler can work either before or after > register allocation, but it is currently tuned to work after. > > The scheduler was bootstrapped and tested on ia64, with all default > languages, both as a first and as a second scheduler. It was also > bootstrapped with c, c++, and fortran enabled on ppc64 and x86-64. > > On ia64, test results on SPEC2k FP comparing -O3 -ffast-math on trunk > and sel-sched branch show 3.8% speedup on average, SPEC INT shows both > small speedups and regressions, staying around neutral in average: > Congratulation! I followed the project for a long time. Finally some useful milestone is achieved and you have got a pretty big improvement. The scheduling algorithm is superior than what we had because it permits to improve insn schedules on all execution paths by insn cloning and other transformations. > On power6, Revital Eres saw speedups on several tests; additional > tuning is required to get good results there, which is complicated > because we don't have power6. On cell, there was some third-party > testing in 2007, showing 4-6% speedups, but I don't have more detailed > information. > > Compile time slowdown measured with --enable-checking=assert is quite > significant -- about 12% on spec int and about 18% on spec fp and > cc1-i-files collection. For this reason, we have enabled selective > scheduler by default at -O3 on ia64 and disabled by default on other > targets. > Itanium is pretty specific target. It would be interesting to know how big a slowdown for ppc. > Our current plan is to work on further compile time improvements and > performance tuning for ppc and cell, hopefully with the help of IBM > Haifa folks. If we will complete this work before the end of stage2, > then we can enable selective scheduling at -O3 also for ppc in 4.4. > In the mid-term, we will work on removing the ebb scheduler, as it is > now used on ia64 only and will be superseded by selective scheduler > when we'll further improve compile time. > I think we should rid of EBB scheduler finally. You could try to improve compile-time problem preventing some transformations in the new scheduler in -O2 mode. If you solve compile-time problem, I think we should work on removing haifa-scheduler too to have just one insn scheduler. But as I understand it will not happen soon.