From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16856 invoked by alias); 5 Jun 2008 18:29:37 -0000 Received: (qmail 16846 invoked by uid 22791); 5 Jun 2008 18:29:36 -0000 X-Spam-Check-By: sourceware.org Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.198.201) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jun 2008 18:29:09 +0000 Received: from [83.149.198.220] (bonzo.ispras.ru [83.149.198.220]) by smtp.ispras.ru (Postfix) with ESMTP id DF8375D4162; Thu, 5 Jun 2008 22:27:30 +0400 (MSD) Message-ID: <48483071.4010906@ispras.ru> Date: Thu, 05 Jun 2008 18:29:00 -0000 From: Andrey Belevantsev User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Steven Bosscher CC: gcc-patches , Jim Wilson , Vladimir Makarov Subject: Re: [RFC] Selective scheduling pass References: <571f6b510806042343y599633e0kd2ef40e9a649e924@mail.gmail.com> In-Reply-To: <571f6b510806042343y599633e0kd2ef40e9a649e924@mail.gmail.com> 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/msg00274.txt.bz2 Steven Bosscher wrote: > (xf. http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00114.html) > > Hi Andrey, > > Thanks for this very nice work. I was wondering if you could say a > little more about the performance impact of the selective scheduler on > the generated code... Thank you Steven! > You posted SPEC scores and there are as many ups as there are downs in > there. Where do the regressions come from? The 3-5% on e.g. galgel > and vortex are quite substantial slowdowns, but do you know why they > happen? We have tried to fix all regressions for which we have found a culprit. Galgel slows down because of two things. First, we cannot use cselib as the ebb scheduler does, because it works only on extended basic blocks. We tried to support cselib for multiple fences, analogously to what we did with target contexts, but we didn't manage to make it work well. I think that we can turn cselib on at least for those regions that are ebbs. The second problem of galgel is that the heuristic that restricts pipelining on small loops doesn't work well in this case. However, we have turned it on because overall it provided a speedup. I would note that on SPEC FP, to which went the most tuning, there are far more ups then downs :) > Also, you post a new scheduler and a set of target tunings in one set > of patches. I would like to know what the performance impact is of > just the target changes alone. That is, what happens to e.g. SPEC > scores for ia64 with just the tweaks and tunings patch > (http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00117.html)? I assume > those target changes alone (the ones not related to sel-sched) also > have a positive performance impact. Since you've globbed everything > into one patch set, it's impossible to tell how much of the > performance changes can be attributed to sel-sched, and how much is > just target tweaks... AFAIR, the target tunings gave around 1% when we have tested it on -O2. That was a couple of months ago. We will retest tonight to get fresh numbers for this. Andrey