From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29068 invoked by alias); 25 Aug 2011 18:08:01 -0000 Received: (qmail 29059 invoked by uid 22791); 25 Aug 2011 18:08:00 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Aug 2011 18:07:45 +0000 Received: by wwi18 with SMTP id 18so2518798wwi.8 for ; Thu, 25 Aug 2011 11:07:44 -0700 (PDT) Received: by 10.227.200.212 with SMTP id ex20mr35127wbb.89.1314295664026; Thu, 25 Aug 2011 11:07:44 -0700 (PDT) Received: from localhost (rsandifo.gotadsl.co.uk [82.133.89.107]) by mx.google.com with ESMTPS id gb10sm648040wbb.56.2011.08.25.11.07.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Aug 2011 11:07:43 -0700 (PDT) From: Richard Sandiford To: Vladimir Makarov Mail-Followup-To: Vladimir Makarov ,"gcc-patches\@gcc.gnu.org" , richard.sandiford@linaro.org, rdsandiford@googlemail.com Cc: "gcc-patches\@gcc.gnu.org" , richard.sandiford@linaro.org Subject: Re: patch to solve recent SPEC2000 degradation References: <4E54329B.5040701@redhat.com> <4E567828.7050800@redhat.com> Date: Thu, 25 Aug 2011 18:52:00 -0000 In-Reply-To: <4E567828.7050800@redhat.com> (Vladimir Makarov's message of "Thu, 25 Aug 2011 12:28:24 -0400") Message-ID: <87mxex4b6b.fsf@firetop.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2011-08/txt/msg02096.txt.bz2 Vladimir Makarov writes: > On 08/25/2011 05:57 AM, Richard Sandiford wrote: >> Vladimir Makarov writes: >>> Instead of using explicitly necessary number of registers, I used >>> contains_reg_of_mode which also checks the number of necessary registers >>> but also it checks that the register class can hold value of given >>> mode. This resulted in different register pressure classes (before the >>> patch, they were GENERAL_REGS and FLOAT_REGS for x86. They became only >>> INT_FLOAT_REGS) because it became not costly to hold integer mode value >>> in FLOAT_REGS. The new register pressure class in own turn resulted in >>> low register pressure and one region allocation in most cases instead of >>> multiple region RA. As a consequence, we got a big degradation on Intel >>> 32 bit targets. >> Sorry, I know I should be able to work this out, but could you explain >> in a bit more detail why contains_reg_of_mode (CL1, MODE) was wrong? >> The loop is calculating costs for moving values of mode MODE into and >> out of CL1, and I wouldn't have expected those costs to have any meaning >> if CL1 can't in fact store anything of mode MODE. >> > Here is x86 example. For an integer mode it excludes FLOAT_REGS from > updating max register move cost for two FLOAT_INT_REGS and the integer > mode in the loop. At the end of function in another loop where > ira_register_move_cost is defined more accurately from > ira_max_register_move_cost, it results in smaller ira_register_move_cost > for two FLOAT_INT_REGS and integer modes than ira_memory_move_cost for > FLOAT_INT_REGS and integer mode. But isn't that correct though? If FLOAT_REGS can't store integer modes, and if FLOAT_INT_REGS is the union of FLOAT_REGS and INT_REGS, then doesn't it follow that the move cost for FLOAT_INT_REGS should be the same as for INT_REGS? To be clear, I'm not disputing that the pressure class changes were undesirable. I'm just not sure why changing the move costs in this way is the right way to get back to the desired pressure classes. If FLOAT_REGS can't store integer modes, then it doesn't seem like we should be taking the reported move cost for FLOAT_REGS and integer modes into account. I'm just not sure that those costs (or CLASS_MAX_NREGS) are meaningful in this case. Richard