From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Richard.Earnshaw@foss.arm.com>
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by sourceware.org (Postfix) with ESMTP id 93260385EC4E
 for <gcc@gcc.gnu.org>; Fri, 11 Sep 2020 13:30:51 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 93260385EC4E
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=foss.arm.com
Authentication-Results: sourceware.org;
 spf=none smtp.mailfrom=Richard.Earnshaw@foss.arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 10CE3106F;
 Fri, 11 Sep 2020 06:30:51 -0700 (PDT)
Received: from [192.168.1.19] (unknown [172.31.20.19])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E91D3F68F;
 Fri, 11 Sep 2020 06:30:50 -0700 (PDT)
Subject: Re: A problem with one instruction multiple latencies and pipelines
To: "Qian, Jianhua" <qianjh@cn.fujitsu.com>, "gcc@gcc.gnu.org"
 <gcc@gcc.gnu.org>
References: <d005a34135eb46e185aaaa38cc8d30b7@G08CNEXMBPEKD06.g08.fujitsu.local>
From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
Message-ID: <e6c69116-2d7b-03fd-80e4-4cbdac2ba0be@foss.arm.com>
Date: Fri, 11 Sep 2020 14:30:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <d005a34135eb46e185aaaa38cc8d30b7@G08CNEXMBPEKD06.g08.fujitsu.local>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3494.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2020 13:30:52 -0000

On 07/09/2020 07:08, Qian, Jianhua wrote:
> Hi
> 
> I'm adding a new machine model. I have a problem when writing the "define_insn_reservation" for instruction scheduling.
> How to write the "define_insn_reservation" for one instruction that there are different latencies and pipelines according to parameter.
> 
> For example, the ADD (shifted register) instruction in a64fx
> 
> Instruction            Option                             Latency    Pipeline
> ADD (shifted register)  <amount> = 0                     1          EX* | EAG*
>                       <amount> = [1-4] && <shift>=LSL  1+1       (EXA + EXA) | (EXB + EXB)
>                                                          2+1       (EXA + EXA) | (EXB + EXB)
> 

A shift by immediate zero isn't a shift, so should never use this RTL
pattern.  We can ignore that case.

> In aarch64.md ADD (shifted register) instruction is defined as following．
>  (define_insn "*add_<shift>_<mode>"
>   [(set (match_operand:GPI 0 "register_operand" "=r")
>         (plus:GPI (ASHIFT:GPI (match_operand:GPI 1 "register_operand" "r")
>                               (match_operand:QI 2 "aarch64_shift_imm_<mode>" "n"))
>                   (match_operand:GPI 3 "register_operand" "r")))]
>   ""
>   "add\\t%<w>0, %<w>3, %<w>1, <shift> %2"
>   [(set_attr "type" "alu_shift_imm")]
> )

You might consider using a define_bypass to adjust the cost - the
matcher rule takes a producer and consumer RTL - you don't care about
the consumer, but you can use the bypass to reduce the cost if the
producer uses an immediate in the 'low latency' range.  This would avoid
having to make a load of whole-sale changes to the main parts of the
machine description.


> 
> It could not be distinguished by the type "alu_shift_imm" when writing "define_insn_reservation" for ADD (shifted register). 
> What should I do?
> 
> Regards
> Qian
> 
> 
> 

R.