From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 83F49384A87E for ; Mon, 7 Sep 2020 11:59:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 83F49384A87E Received: by mail-ej1-x62d.google.com with SMTP id r7so4528281ejs.11 for ; Mon, 07 Sep 2020 04:59:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HrUEL4aaTK4IB9zSFDnTZBR57KR3lThLKgegDd9vNdQ=; b=AgdPcFa/M2oWyG3dRYF5P7DxpnQmnEXZ6NPLuFd8wafGm9Ymd8gwGL/J+6AGmM2+/f u0U8FdLcPOm9myKL0tgmtCGW0eXd8Pnru6DWLXyzUAIaQsu6bM9IjFz+FhRAnNQsPhuS D9jj2iFwqE6D+drMpFIXH9PGo+8OHFL+kYXmPWN+tJHQlMQj5+W5NpUoXi9spWS/sFuo goEocsZl+bSlnJ0ARNvACvLLJrkSqIC5QgKFKQq7HkQzlJr32+5l7+aKGf7AD0W3vsNi juGFkOof5Z27VRl+V+/55sNvClaed1V4OoShGlaQSs0wNlzxWiNx+VfWotBFuLaRuFdm WVcw== X-Gm-Message-State: AOAM533DsfXFgxwQEZg21E8UOq9HPWXBF1pAX+oYY93tYRcRZNqx1Y9P 4Zu9qEZJF7I/byX6lKlHY7lTEOQZEScjY4T7tEA= X-Google-Smtp-Source: ABdhPJx1OsjDCPD8FzmbtpWRgUcJEpLYEeGxoKhg92MnhR6SuA8IIMFiU0ZulIxIlEzH6jHKAtl3zQ80fB1cmDPvy44= X-Received: by 2002:a17:906:2cd2:: with SMTP id r18mr16441784ejr.371.1599479948659; Mon, 07 Sep 2020 04:59:08 -0700 (PDT) MIME-Version: 1.0 References: <33fe6dd916554306847d4d31efbb0ae4@G08CNEXMBPEKD06.g08.fujitsu.local> In-Reply-To: <33fe6dd916554306847d4d31efbb0ae4@G08CNEXMBPEKD06.g08.fujitsu.local> From: Richard Biener Date: Mon, 7 Sep 2020 13:58:57 +0200 Message-ID: Subject: Re: A problem with one instruction multiple latencies and pipelines To: "Qian, Jianhua" Cc: "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 11:59:11 -0000 On Mon, Sep 7, 2020 at 10:46 AM Qian, Jianhua wrote= : > > Hi Richard > > > -----Original Message----- > > From: Richard Biener > > Sent: Monday, September 7, 2020 3:41 PM > > To: Qian, Jianhua/=E9=92=B1 =E5=BB=BA=E5=8D=8E > > Cc: gcc@gcc.gnu.org > > Subject: Re: A problem with one instruction multiple latencies and pipe= lines > > > > On Mon, Sep 7, 2020 at 8:10 AM Qian, Jianhua wr= ote: > > > > > > 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 t= here are > > different latencies and pipelines according to parameter. > > > > > > For example, the ADD (shifted register) instruction in a64fx > > > > > > Instruction Option Latency > > Pipeline > > > ADD (shifted register) =3D 0 1 = EX* > > | EAG* > > > =3D [1-4] && =3DLSL 1+1 > > (EXA + EXA) | (EXB + EXB) > > > 2+1 (E= XA > > + EXA) | (EXB + EXB) > > > > > > In aarch64.md ADD (shifted register) instruction is defined as follow= ing=EF=BC=8E > > > (define_insn "*add__" > > > [(set (match_operand:GPI 0 "register_operand" "=3Dr") > > > (plus:GPI (ASHIFT:GPI (match_operand:GPI 1 "register_operand" > > "r") > > > (match_operand:QI 2 > > "aarch64_shift_imm_" "n")) > > > (match_operand:GPI 3 "register_operand" "r")))] > > > "" > > > "add\\t%0, %3, %1, %2" > > > [(set_attr "type" "alu_shift_imm")] > > > ) > > > > > > It could not be distinguished by the type "alu_shift_imm" when writin= g > > "define_insn_reservation" for ADD (shifted register). > > > What should I do? > > > > Just a guess - I'm not very familiar with the pipeline modeling, you pr= obably > > need to expose two alternatives so you can assign a different type to t= he second > > one. > I'm considering such method, > but if I do that I'm afraid it has side effects on other machine models o= f aarch64 series. > Some instructions' definition will be changed in aarch64.md file. > > > Other than that modeling the more restrictive (or permissive?) variant = might > > work good enough in practice. > Is your mean that an approximate modeling is good enough? Yes. > > a64fx is probably out-of-order anyway. > Yes, a64fx is an out-of-order architecture. > > Regards > Qian > > > > > Richard. > > > > > Regards > > > Qian > > > > > > > > > > > > > >