From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-166518-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12970 invoked by alias); 13 Jan 2011 05:50:23 -0000
Received: (qmail 12960 invoked by uid 22791); 13 Jan 2011 05:50:22 -0000
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST
X-Spam-Check-By: sourceware.org
Received: from mail-iy0-f175.google.com (HELO mail-iy0-f175.google.com) (209.85.210.175)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Jan 2011 05:50:17 +0000
Received: by iyj18 with SMTP id 18so1317534iyj.20        for <gcc@gcc.gnu.org>; Wed, 12 Jan 2011 21:50:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.239.2 with SMTP id ku2mr2044977icb.497.1294897815165; Wed, 12 Jan 2011 21:50:15 -0800 (PST)
Received: by 10.42.3.147 with HTTP; Wed, 12 Jan 2011 21:50:15 -0800 (PST)
In-Reply-To: <4D260AC3.8080105@codesourcery.com>
References: <AANLkTimhP_2mewXieOCg0ppKNrx2084V1Okes69_5q6v@mail.gmail.com>	<87ipyacba8.fsf@firetop.home>	<4D260AC3.8080105@codesourcery.com>
Date: Thu, 13 Jan 2011 05:50:00 -0000
Message-ID: <AANLkTinrLck=0R+2aijaVHCAn2fp7JGNhc3nCpM8q-6C@mail.gmail.com>
Subject: Re: [MIPS] Test case dspr2-MULT is failed
From: Mingjie Xing <mingjie.xing@gmail.com>
To: Chung-Lin Tang <cltang@codesourcery.com>
Cc: gcc@gcc.gnu.org, rdsandiford@googlemail.com
Content-Type: text/plain; charset=ISO-8859-1
X-IsSubscribed: yes
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2011-01/txt/msg00158.txt.bz2

2011/1/7 Chung-Lin Tang <cltang@codesourcery.com>:
> I analyzed this testcase regression a while earlier; the direct cause of
> this is due to mips_order_regs_for_local_alloc(), which now serves as
> MIPS' ADJUST_REG_ALLOC_ORDER macro.
>
> The mips_order_regs_for_local_alloc() function seems to be written for
> the old local-alloc.c, still left as the deprecated
> ORDER_REGS_FOR_LOCAL_ALLOC macro after the transition to IRA (actually
> not called at all during then), and relatively recently 'revived' after
> a patch by Bernd that created the ADJUST_REG_ALLOC_ORDER macro went in.
>
> So you have a local-alloc.c heuristic working in IRA, which seemed to
> cause these regressions.
>
> Removing mips_order_regs_for_local_alloc() will let this testcase pass;
> of course the real fix should be to review the MIPS reg-ordering logic,
> left for you MIPS people...
>
> Chung-Lin
>

As I can see, mips_order_regs_for_local_alloc() is only used to
reorder $24 (T_REG) for MIPS16.  Since current definition of
REG_ALLOC_ORDER for IRA is not {0,1,2,...} any more, the old loop
code,

  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
    reg_alloc_order[i] = i;

in mips_order_regs_for_local_alloc() seems inadequate.  Because this
will override the definition of REG_ALLOC_ORDER.

Anyway, when I tried to rewrite the function to keep the register
order, the testcase is passed, but I can't see the speedup on my port.

Thanks,
Mingjie