| Message ID | 20211217154251.GA4694@arm.com |
|---|---|
| State | Committed |
| Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org>
X-Original-To: patchwork@sourceware.org
Delivered-To: patchwork@sourceware.org
Received: from server2.sourceware.org (localhost [IPv6:::1])
by sourceware.org (Postfix) with ESMTP id 3EB9B3858010
for <patchwork@sourceware.org>; Fri, 17 Dec 2021 15:45:17 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3EB9B3858010
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
s=default; t=1639755917;
bh=6Gpfx7jh1kAAJgeF6hcY/AA+ol6imHo/37c+eWmCudY=;
h=Date:To:Subject:In-Reply-To:List-Id:List-Unsubscribe:List-Archive:
List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:From;
b=SzmvstnSDPcKVB500P+n/EKZ1VlmYVHq/NpoCcT1XyToID3Y5Sjw4m59TcJVR2jNl
0OVT+qgEFPU+rc+OVU1HY/RKkW8lYcFUKranCP0JNzc9GFAGy4hOV78QNP4zgV/pRP
Z/15NTlFnGbk/w7EiCTdLk6iUT9N346/4/a5PMvM=
X-Original-To: gcc-patches@gcc.gnu.org
Delivered-To: gcc-patches@gcc.gnu.org
Received: from EUR01-VE1-obe.outbound.protection.outlook.com
(mail-eopbgr140081.outbound.protection.outlook.com [40.107.14.81])
by sourceware.org (Postfix) with ESMTPS id 7F3B73858412
for <gcc-patches@gcc.gnu.org>; Fri, 17 Dec 2021 15:43:10 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7F3B73858412
Received: from AM3PR07CA0105.eurprd07.prod.outlook.com (2603:10a6:207:7::15)
by AM9PR08MB6051.eurprd08.prod.outlook.com (2603:10a6:20b:2d6::19) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.14; Fri, 17 Dec
2021 15:43:07 +0000
Received: from VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com
(2603:10a6:207:7:cafe::f1) by AM3PR07CA0105.outlook.office365.com
(2603:10a6:207:7::15) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.8 via Frontend
Transport; Fri, 17 Dec 2021 15:43:07 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
smtp.mailfrom=arm.com; dkim=pass (signature was verified)
header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
63.35.35.123 as permitted sender) receiver=protection.outlook.com;
client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
VE1EUR03FT010.mail.protection.outlook.com (10.152.18.113) with
Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.4801.14 via Frontend Transport; Fri, 17 Dec 2021 15:43:06 +0000
Received: ("Tessian outbound c61f076cbd30:v110");
Fri, 17 Dec 2021 15:43:06 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: c9303553868c5953
X-CR-MTA-TID: 64aa7808
Received: from 8d7c88051f4f.2
by 64aa7808-outbound-1.mta.getcheckrecipient.com id
5159F57C-DCDD-4FCD-BD33-90EC4FBF21B1.1;
Fri, 17 Dec 2021 15:42:59 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
8d7c88051f4f.2
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
Fri, 17 Dec 2021 15:42:59 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=b/k3DrXnfBmn+TLKRHmfBh1k1lFtPiHKG/2JoqjvPVNi0ywlxwm+Ku5nDU8kKKHPWFITZu8qeVGO/yxUk7r4R1ulFPThuJ+SI78yPQyFEA1q6/zoes5Iz9UIYW2s/oqThGR7fI5Zp0IJXOCse4W+ocO+KmaOlbs4+lJXB4KWmGqZzAePfel9YEVI724ljFU1RGsl0uXg0NIOExt5kTFnOFXNxSCz+T81/tPGxvv9/Q6FM/s/1qdzqrMZsVKaeARRtEo8/WfT91ep2Ly4VFtaj358NeF31CxW1NtRiw3PqFpwVtYgBS+IRN4BfNOrVPnmyrngQX04u6T49KyXAnFQ0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=6Gpfx7jh1kAAJgeF6hcY/AA+ol6imHo/37c+eWmCudY=;
b=IBBjZrbkZzgwQnSC7o9K8HwR7KEheTtkicP6K/15Q81Q7bCxp3d0X07gE6Hu666gvWBqqjG7H+V6aGRoNNAoicy9pqTNKeS1/RDHK5MQrFNRDuyqeqEp0AFIfCZVz1umhvghMMgtTBMp1tBu0pQlT4GDTvIsN14gl5p99P0UObF1jfyAXu4MVXdVjFZB45JfCb6JFuE6X4JWTbFzhJeYF51UebsqZuiLfY6Yj2mJFOygehtbrCMyvjdRv+Ik/h0YAoa+c1yJaodd9tzMEHmrh1MgsL2HsGNEjlZOHWx57pnurtFQEAH51BqcXb6iIDEnCw3cB2t/SLucG7L/Z36aUQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
header.d=arm.com; arc=none
Authentication-Results-Original: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=arm.com;
Received: from VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17)
by VE1PR08MB4863.eurprd08.prod.outlook.com (2603:10a6:802:ac::10)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.14; Fri, 17 Dec
2021 15:42:57 +0000
Received: from VI1PR08MB5325.eurprd08.prod.outlook.com
([fe80::12a:3d2c:81ff:8fcc]) by VI1PR08MB5325.eurprd08.prod.outlook.com
([fe80::12a:3d2c:81ff:8fcc%8]) with mapi id 15.20.4778.018; Fri, 17 Dec 2021
15:42:57 +0000
Date: Fri, 17 Dec 2021 15:42:53 +0000
To: gcc-patches@gcc.gnu.org
Subject: [2/3 PATCH]AArch64 use canonical ordering for complex mul, fma and
fms
Message-ID: <20211217154251.GA4694@arm.com>
Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf"
Content-Disposition: inline
In-Reply-To: <patch-15145-tamar@arm.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-ClientProxiedBy: LO2P265CA0369.GBRP265.PROD.OUTLOOK.COM
(2603:10a6:600:a3::21) To VI1PR08MB5325.eurprd08.prod.outlook.com
(2603:10a6:803:13e::17)
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 9c42066a-d3d5-4dc4-5bdf-08d9c173ebac
X-MS-TrafficTypeDiagnostic:
VE1PR08MB4863:EE_|VE1EUR03FT010:EE_|AM9PR08MB6051:EE_
X-Microsoft-Antispam-PRVS:
<AM9PR08MB6051603808B75ADCB251A8AFFF789@AM9PR08MB6051.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Oob-TLC-OOBClassifiers: OLM:4303;OLM:4303;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original:
T5/Kjg+ul4fmXq5P8LVr8paEBHyUHVWzVwCue8kE12WzCy+5xgDh5L/5RWvAEWaz9KW+7Kh9y/euhMajqiXkqIGzfnc4qEjzFjsT375EPHtGBgVQUCANteGC5jaI+t36bl8Noqkqp6o8F1HhMxUb99cQeFIUAVph3Rv9wooSh/ArEwrCcOTV083TYYI9O25wmYA0zZPUwAhe3ta+pZJE2/+f47SOruzPdzWlJfDU22YwkEiQQw87594mRiA9kJ27oPuduq2yEGPoK1pb/rcISUVHwKookWqTkikgg/hW+jimmhabiIW86khmAzQKFjtSqWvwSOEPb543zh/zuCQHsODURbNzirj8+DzMPH6RpIuEBnHjkwC3OuVHdlnKzcO0pd0ZvI+7V32m3pLqj47XFBd63faBX48peGFNqeualatGbPwEO1zioh2VtV1RmYLxfwrhPcBPBSEhKsH97ew0gPN8AMwKtpnet8CwECj3PJHsmSGmOq1V3E2bjBkrbFITpgN6gJ/bJzg1qCyU5tMLRtSqsbS+6BedUtt4P0tI0eu6ONupvyKvDzIA3jm+Q3qCZHdmlGhAwgdNb0jvekmHk8dxg1Mtn0V+LznpNXY5D33t7GNnH8KPheduQpBIbs+5RqAUbXrHigbqq+M/V5IdenE5bHGPHB/mE43tPlaKOzdXy9C8pfQ+ArEg+16QL2pi6wWlL+e6bvEX0x2H6Eez2cYQ6NDC8T0hzKEVxhPe/Kk=
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en;
SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB5325.eurprd08.prod.outlook.com;
PTR:; CAT:NONE;
SFS:(4636009)(366004)(52116002)(2906002)(6916009)(86362001)(508600001)(6486002)(26005)(6506007)(33964004)(186003)(8676002)(44144004)(8936002)(5660300002)(316002)(33656002)(66476007)(235185007)(66946007)(1076003)(36756003)(2616005)(38350700002)(6512007)(38100700002)(66556008)(4743002)(4326008)(6666004)(83380400001)(44832011)(2700100001);
DIR:OUT; SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4863
Original-Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
e8a2b130-2ede-4d36-4352-08d9c173e609
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
ycUvkIQASmdKDMSkLSr/yeyutCazRuCQKrOPpWJsPPuRzQEe+gUVmOXKiTUd3GBRalRifHrsrzMtDpjyDLhdUsCijdTFTJVXJKu0xYAilNi9n/oFgCzVqz/fTDcLpG9F0ZNHGYoR2T5E++wJ5ut6xNFF7x9YJQzq3N0v9M/CNObjLnNE1xDbT0tdPAnV3HFoXz60LsjVNK+vbsgrPmyxKbF0No9KGDabeMeKwqYG4ZTseHZvHzB6433AWh2pvXGFw2nDJ7uqvl+A1Oc8BQusdz3FBwUz5nX8Irv4xkTa63oWECaHrWGqd71IVG81b8VOls06R0WoNRGS+53DGJydXdt2bbicy4KV/VC9p2jJ9VHIn/HvXDf4Fj8kAlXWTHxQdarplZV2TgC9qT9mTP19c03HVUIlfgGzbLwApTOzzWEBvJNiU3YT3xrIWiquSw2NG/B+cGwZhC3XHo0296P2EG6bQPPs+lPDVJHEEhuBpOLu3t0ZHc9LMT/HjpNOvt4IWswFI4YNblJZzRUessokbuxfxVIStLY1kAzFVXnrUbIlUnaVQgpj+3krPpBrAdL7BiESlE5oYXsCOwtr3yBw6e+QftlKEI75zdx3k/u0lpojj0RXYr80aNeu8MB7DZSoqMZqkxVC/rQEusgIzMb+faHe5i1YX3YcEB6Ng7Jt0ks3kZ2YRovsrXdRFZzZTj3KWVStAWv+7r+ICR5d/hIUuN0U/OVzNONvzBBx8aIPQNc=
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;
IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;
PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE;
SFS:(4636009)(36840700001)(46966006)(8676002)(44832011)(36756003)(2616005)(33656002)(4326008)(6666004)(6486002)(47076005)(26005)(8936002)(1076003)(6506007)(70586007)(6916009)(6512007)(186003)(336012)(86362001)(44144004)(83380400001)(2906002)(33964004)(36860700001)(70206006)(5660300002)(81166007)(356005)(4743002)(82310400004)(508600001)(235185007)(316002)(2700100001);
DIR:OUT; SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2021 15:43:06.7554 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id:
9c42066a-d3d5-4dc4-5bdf-08d9c173ebac
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp:
TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];
Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6051
X-Spam-Status: No, score=-13.5 required=5.0 tests=BAYES_00, DKIM_SIGNED,
DKIM_VALID, GIT_PATCH_0, KAM_LOTSOFHASH, RCVD_IN_DNSWL_NONE,
RCVD_IN_MSPIKE_H2,
SPF_HELO_PASS, SPF_PASS, TXREP,
UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
<mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
<mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
From: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org>
Reply-To: Tamar Christina <tamar.christina@arm.com>
Cc: Richard.Earnshaw@arm.com, nd@arm.com, richard.sandiford@arm.com,
Marcus.Shawcroft@arm.com
Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org
Sender: "Gcc-patches"
<gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org>
|
| Series |
[1/3] middle-end vect: Simplify and extend the complex numbers validation routines.
|
|
Commit Message
Tamar Christina
Dec. 17, 2021, 3:42 p.m. UTC
Hi All, After the first patch in the series this updates the optabs to expect the canonical sequence. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? and backport along with the first patch? Thanks, Tamar gcc/ChangeLog: PR tree-optimization/102819 PR tree-optimization/103169 * config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4, cmul<conj_op><mode>3): Use canonical order. * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4, cmul<conj_op><mode>3): Likewise. --- inline copy of patch -- diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..875896ee71324712c8034eeff9cfb5649f9b0e73 100644 --
Comments
Tamar Christina <tamar.christina@arm.com> writes: > Hi All, > > After the first patch in the series this updates the optabs to expect the > canonical sequence. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? and backport along with the first patch? > > Thanks, > Tamar > > gcc/ChangeLog: > > PR tree-optimization/102819 > PR tree-optimization/103169 > * config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4, > cmul<conj_op><mode>3): Use canonical order. > * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4, > cmul<conj_op><mode>3): Likewise. > > --- inline copy of patch -- > diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md > index f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..875896ee71324712c8034eeff9cfb5649f9b0e73 100644 > --- a/gcc/config/aarch64/aarch64-simd.md > +++ b/gcc/config/aarch64/aarch64-simd.md > @@ -556,17 +556,17 @@ (define_insn "aarch64_fcmlaq_lane<rot><mode>" > ;; remainder. Because of this, expand early. > (define_expand "cml<fcmac1><conj_op><mode>4" > [(set (match_operand:VHSDF 0 "register_operand") > - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") > - (unspec:VHSDF [(match_operand:VHSDF 2 "register_operand") > - (match_operand:VHSDF 3 "register_operand")] > - FCMLA_OP)))] > + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 "register_operand") > + (match_operand:VHSDF 2 "register_operand")] > + FCMLA_OP) > + (match_operand:VHSDF 3 "register_operand")))] > "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" > { > rtx tmp = gen_reg_rtx (<MODE>mode); > - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], > - operands[3], operands[2])); > + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], > + operands[1], operands[2])); > emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, > - operands[3], operands[2])); > + operands[1], operands[2])); > DONE; > }) > > @@ -583,9 +583,9 @@ (define_expand "cmul<conj_op><mode>3" > rtx tmp = force_reg (<MODE>mode, CONST0_RTX (<MODE>mode)); > rtx res1 = gen_reg_rtx (<MODE>mode); > emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (res1, tmp, > - operands[2], operands[1])); > + operands[1], operands[2])); > emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], res1, > - operands[2], operands[1])); > + operands[1], operands[2])); This doesn't look right. Going from the documentation, patch 1 isn't changing the operand order for CMUL: the conjugated operand (if there is one) is still operand 2. The FCMLA sequences use the opposite order, where the conjugated operand (if there is one) is operand 1. So I think the reversal here is still needed. Same for the multiplication operands in CML* above. Thanks, Richard
Richard Sandiford <richard.sandiford@arm.com> writes: > Tamar Christina <tamar.christina@arm.com> writes: >> Hi All, >> >> After the first patch in the series this updates the optabs to expect the >> canonical sequence. >> >> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >> >> Ok for master? and backport along with the first patch? >> >> Thanks, >> Tamar >> >> gcc/ChangeLog: >> >> PR tree-optimization/102819 >> PR tree-optimization/103169 >> * config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4, >> cmul<conj_op><mode>3): Use canonical order. >> * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4, >> cmul<conj_op><mode>3): Likewise. >> >> --- inline copy of patch -- >> diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md >> index f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..875896ee71324712c8034eeff9cfb5649f9b0e73 100644 >> --- a/gcc/config/aarch64/aarch64-simd.md >> +++ b/gcc/config/aarch64/aarch64-simd.md >> @@ -556,17 +556,17 @@ (define_insn "aarch64_fcmlaq_lane<rot><mode>" >> ;; remainder. Because of this, expand early. >> (define_expand "cml<fcmac1><conj_op><mode>4" >> [(set (match_operand:VHSDF 0 "register_operand") >> - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") >> - (unspec:VHSDF [(match_operand:VHSDF 2 "register_operand") >> - (match_operand:VHSDF 3 "register_operand")] >> - FCMLA_OP)))] >> + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 "register_operand") >> + (match_operand:VHSDF 2 "register_operand")] >> + FCMLA_OP) >> + (match_operand:VHSDF 3 "register_operand")))] >> "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" >> { >> rtx tmp = gen_reg_rtx (<MODE>mode); >> - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], >> - operands[3], operands[2])); >> + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], >> + operands[1], operands[2])); >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, >> - operands[3], operands[2])); >> + operands[1], operands[2])); >> DONE; >> }) >> >> @@ -583,9 +583,9 @@ (define_expand "cmul<conj_op><mode>3" >> rtx tmp = force_reg (<MODE>mode, CONST0_RTX (<MODE>mode)); >> rtx res1 = gen_reg_rtx (<MODE>mode); >> emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (res1, tmp, >> - operands[2], operands[1])); >> + operands[1], operands[2])); >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], res1, >> - operands[2], operands[1])); >> + operands[1], operands[2])); > > This doesn't look right. Going from the documentation, patch 1 isn't > changing the operand order for CMUL: the conjugated operand (if there > is one) is still operand 2. The FCMLA sequences use the opposite order, > where the conjugated operand (if there is one) is operand 1. So I think I meant “the first multiplication operand” rather than “operand 1” here. > the reversal here is still needed. > > Same for the multiplication operands in CML* above. > > Thanks, > Richard
> -----Original Message----- > From: Richard Sandiford <richard.sandiford@arm.com> > Sent: Friday, December 17, 2021 4:49 PM > To: Tamar Christina <Tamar.Christina@arm.com> > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com>; Richard Earnshaw > <Richard.Earnshaw@arm.com>; Marcus Shawcroft > <Marcus.Shawcroft@arm.com>; Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> > Subject: Re: [2/3 PATCH]AArch64 use canonical ordering for complex mul, > fma and fms > > Richard Sandiford <richard.sandiford@arm.com> writes: > > Tamar Christina <tamar.christina@arm.com> writes: > >> Hi All, > >> > >> After the first patch in the series this updates the optabs to expect > >> the canonical sequence. > >> > >> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > >> > >> Ok for master? and backport along with the first patch? > >> > >> Thanks, > >> Tamar > >> > >> gcc/ChangeLog: > >> > >> PR tree-optimization/102819 > >> PR tree-optimization/103169 > >> * config/aarch64/aarch64-simd.md > (cml<fcmac1><conj_op><mode>4, > >> cmul<conj_op><mode>3): Use canonical order. > >> * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4, > >> cmul<conj_op><mode>3): Likewise. > >> > >> --- inline copy of patch -- > >> diff --git a/gcc/config/aarch64/aarch64-simd.md > >> b/gcc/config/aarch64/aarch64-simd.md > >> index > >> > f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..875896ee71324712c8034eeff9 > c > >> fb5649f9b0e73 100644 > >> --- a/gcc/config/aarch64/aarch64-simd.md > >> +++ b/gcc/config/aarch64/aarch64-simd.md > >> @@ -556,17 +556,17 @@ (define_insn > "aarch64_fcmlaq_lane<rot><mode>" > >> ;; remainder. Because of this, expand early. > >> (define_expand "cml<fcmac1><conj_op><mode>4" > >> [(set (match_operand:VHSDF 0 "register_operand") > >> - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") > >> - (unspec:VHSDF [(match_operand:VHSDF 2 > "register_operand") > >> - (match_operand:VHSDF 3 > "register_operand")] > >> - FCMLA_OP)))] > >> + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 > "register_operand") > >> + (match_operand:VHSDF 2 > "register_operand")] > >> + FCMLA_OP) > >> + (match_operand:VHSDF 3 "register_operand")))] > >> "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" > >> { > >> rtx tmp = gen_reg_rtx (<MODE>mode); > >> - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], > >> - operands[3], operands[2])); > >> + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], > >> + operands[1], operands[2])); > >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, > >> - operands[3], operands[2])); > >> + operands[1], operands[2])); > >> DONE; > >> }) > >> > >> @@ -583,9 +583,9 @@ (define_expand "cmul<conj_op><mode>3" > >> rtx tmp = force_reg (<MODE>mode, CONST0_RTX (<MODE>mode)); > >> rtx res1 = gen_reg_rtx (<MODE>mode); > >> emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (res1, tmp, > >> - operands[2], operands[1])); > >> + operands[1], operands[2])); > >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], res1, > >> - operands[2], operands[1])); > >> + operands[1], operands[2])); > > > > This doesn't look right. Going from the documentation, patch 1 isn't > > changing the operand order for CMUL: the conjugated operand (if there > > is one) is still operand 2. The FCMLA sequences use the opposite > > order, where the conjugated operand (if there is one) is operand 1. > > So I think > > I meant “the first multiplication operand” rather than “operand 1” here. > > > the reversal here is still needed. > > > > Same for the multiplication operands in CML* above. I did actually change the order in patch 1, but didn't update the docs.. That was done because I followed the SLP order again, but now I've updated them to do what the docs say. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? and backport along with the first patch? Thanks, Tamar gcc/ChangeLog: PR tree-optimization/102819 PR tree-optimization/103169 * config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4): Use canonical order. * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4): Likewise. --- inline copy of patch --- diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..9e41610fba85862ef7675bea1e5731b14cab59ce 100644 --- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -556,17 +556,17 @@ (define_insn "aarch64_fcmlaq_lane<rot><mode>" ;; remainder. Because of this, expand early. (define_expand "cml<fcmac1><conj_op><mode>4" [(set (match_operand:VHSDF 0 "register_operand") - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") - (unspec:VHSDF [(match_operand:VHSDF 2 "register_operand") - (match_operand:VHSDF 3 "register_operand")] - FCMLA_OP)))] + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 "register_operand") + (match_operand:VHSDF 2 "register_operand")] + FCMLA_OP) + (match_operand:VHSDF 3 "register_operand")))] "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" { rtx tmp = gen_reg_rtx (<MODE>mode); - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], - operands[3], operands[2])); + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], + operands[2], operands[1])); emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, - operands[3], operands[2])); + operands[2], operands[1])); DONE; }) diff --git a/gcc/config/aarch64/aarch64-sve.md b/gcc/config/aarch64/aarch64-sve.md index 9ef968840c20a3049901b3f8a919cf27ded1da3e..9ed19017c480b88779e9e3b08c0e031be60a8c12 100644 --- a/gcc/config/aarch64/aarch64-sve.md +++ b/gcc/config/aarch64/aarch64-sve.md @@ -7278,11 +7278,11 @@ (define_expand "cml<fcmac1><conj_op><mode>4" rtx tmp = gen_reg_rtx (<MODE>mode); emit_insn (gen_aarch64_pred_fcmla<sve_rot1><mode> (tmp, operands[4], - operands[3], operands[2], - operands[1], operands[5])); + operands[2], operands[1], + operands[3], operands[5])); emit_insn (gen_aarch64_pred_fcmla<sve_rot2><mode> (operands[0], operands[4], - operands[3], operands[2], + operands[2], operands[1], tmp, operands[5])); DONE; })
ping > -----Original Message----- > From: Tamar Christina > Sent: Monday, December 20, 2021 4:21 PM > To: Richard Sandiford <richard.sandiford@arm.com> > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com>; Richard Earnshaw > <Richard.Earnshaw@arm.com>; Marcus Shawcroft > <Marcus.Shawcroft@arm.com>; Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> > Subject: RE: [2/3 PATCH]AArch64 use canonical ordering for complex > mul, fma and fms > > > > > -----Original Message----- > > From: Richard Sandiford <richard.sandiford@arm.com> > > Sent: Friday, December 17, 2021 4:49 PM > > To: Tamar Christina <Tamar.Christina@arm.com> > > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com>; Richard Earnshaw > > <Richard.Earnshaw@arm.com>; Marcus Shawcroft > > <Marcus.Shawcroft@arm.com>; Kyrylo Tkachov > <Kyrylo.Tkachov@arm.com> > > Subject: Re: [2/3 PATCH]AArch64 use canonical ordering for complex > > mul, fma and fms > > > > Richard Sandiford <richard.sandiford@arm.com> writes: > > > Tamar Christina <tamar.christina@arm.com> writes: > > >> Hi All, > > >> > > >> After the first patch in the series this updates the optabs to > > >> expect the canonical sequence. > > >> > > >> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > >> > > >> Ok for master? and backport along with the first patch? > > >> > > >> Thanks, > > >> Tamar > > >> > > >> gcc/ChangeLog: > > >> > > >> PR tree-optimization/102819 > > >> PR tree-optimization/103169 > > >> * config/aarch64/aarch64-simd.md > > (cml<fcmac1><conj_op><mode>4, > > >> cmul<conj_op><mode>3): Use canonical order. > > >> * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4, > > >> cmul<conj_op><mode>3): Likewise. > > >> > > >> --- inline copy of patch -- > > >> diff --git a/gcc/config/aarch64/aarch64-simd.md > > >> b/gcc/config/aarch64/aarch64-simd.md > > >> index > > >> > > > f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..875896ee71324712c8034eeff9 > > c > > >> fb5649f9b0e73 100644 > > >> --- a/gcc/config/aarch64/aarch64-simd.md > > >> +++ b/gcc/config/aarch64/aarch64-simd.md > > >> @@ -556,17 +556,17 @@ (define_insn > > "aarch64_fcmlaq_lane<rot><mode>" > > >> ;; remainder. Because of this, expand early. > > >> (define_expand "cml<fcmac1><conj_op><mode>4" > > >> [(set (match_operand:VHSDF 0 "register_operand") > > >> - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") > > >> - (unspec:VHSDF [(match_operand:VHSDF 2 > > "register_operand") > > >> - (match_operand:VHSDF 3 > > "register_operand")] > > >> - FCMLA_OP)))] > > >> + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 > > "register_operand") > > >> + (match_operand:VHSDF 2 > > "register_operand")] > > >> + FCMLA_OP) > > >> + (match_operand:VHSDF 3 "register_operand")))] > > >> "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" > > >> { > > >> rtx tmp = gen_reg_rtx (<MODE>mode); > > >> - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], > > >> - operands[3], operands[2])); > > >> + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], > > >> + operands[1], operands[2])); > > >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, > > >> - operands[3], operands[2])); > > >> + operands[1], operands[2])); > > >> DONE; > > >> }) > > >> > > >> @@ -583,9 +583,9 @@ (define_expand "cmul<conj_op><mode>3" > > >> rtx tmp = force_reg (<MODE>mode, CONST0_RTX (<MODE>mode)); > > >> rtx res1 = gen_reg_rtx (<MODE>mode); > > >> emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (res1, tmp, > > >> - operands[2], operands[1])); > > >> + operands[1], operands[2])); > > >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], res1, > > >> - operands[2], operands[1])); > > >> + operands[1], operands[2])); > > > > > > This doesn't look right. Going from the documentation, patch 1 > > > isn't changing the operand order for CMUL: the conjugated operand > > > (if there is one) is still operand 2. The FCMLA sequences use the > > > opposite order, where the conjugated operand (if there is one) is > operand 1. > > > So I think > > > > I meant “the first multiplication operand” rather than “operand 1” here. > > > > > the reversal here is still needed. > > > > > > Same for the multiplication operands in CML* above. > > I did actually change the order in patch 1, but didn't update the docs.. > That was done because I followed the SLP order again, but now I've > updated them to do what the docs say. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? and backport along with the first patch? > > Thanks, > Tamar > > gcc/ChangeLog: > > PR tree-optimization/102819 > PR tree-optimization/103169 > * config/aarch64/aarch64-simd.md > (cml<fcmac1><conj_op><mode>4): Use > canonical order. > * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4): > Likewise. > > --- inline copy of patch --- > > diff --git a/gcc/config/aarch64/aarch64-simd.md > b/gcc/config/aarch64/aarch64-simd.md > index > f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..9e41610fba85862ef7675bea1 > e5731b14cab59ce 100644 > --- a/gcc/config/aarch64/aarch64-simd.md > +++ b/gcc/config/aarch64/aarch64-simd.md > @@ -556,17 +556,17 @@ (define_insn "aarch64_fcmlaq_lane<rot><mode>" > ;; remainder. Because of this, expand early. > (define_expand "cml<fcmac1><conj_op><mode>4" > [(set (match_operand:VHSDF 0 "register_operand") > - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") > - (unspec:VHSDF [(match_operand:VHSDF 2 > "register_operand") > - (match_operand:VHSDF 3 > "register_operand")] > - FCMLA_OP)))] > + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 > "register_operand") > + (match_operand:VHSDF 2 > "register_operand")] > + FCMLA_OP) > + (match_operand:VHSDF 3 "register_operand")))] > "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" > { > rtx tmp = gen_reg_rtx (<MODE>mode); > - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], > - operands[3], operands[2])); > + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], > + operands[2], operands[1])); > emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, > - operands[3], operands[2])); > + operands[2], operands[1])); > DONE; > }) > > diff --git a/gcc/config/aarch64/aarch64-sve.md > b/gcc/config/aarch64/aarch64-sve.md > index > 9ef968840c20a3049901b3f8a919cf27ded1da3e..9ed19017c480b88779e9e3b08 > c0e031be60a8c12 100644 > --- a/gcc/config/aarch64/aarch64-sve.md > +++ b/gcc/config/aarch64/aarch64-sve.md > @@ -7278,11 +7278,11 @@ (define_expand "cml<fcmac1><conj_op><mode>4" > rtx tmp = gen_reg_rtx (<MODE>mode); > emit_insn > (gen_aarch64_pred_fcmla<sve_rot1><mode> (tmp, operands[4], > - operands[3], operands[2], > - operands[1], operands[5])); > + operands[2], operands[1], > + operands[3], operands[5])); > emit_insn > (gen_aarch64_pred_fcmla<sve_rot2><mode> (operands[0], operands[4], > - operands[3], operands[2], > + operands[2], operands[1], > tmp, operands[5])); > DONE; > })
Ping x3. > -----Original Message----- > From: Tamar Christina > Sent: Tuesday, January 11, 2022 7:11 AM > To: Richard Sandiford <richard.sandiford@arm.com> > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com>; Richard Earnshaw > <Richard.Earnshaw@arm.com>; Marcus Shawcroft > <Marcus.Shawcroft@arm.com>; Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> > Subject: RE: [2/3 PATCH]AArch64 use canonical ordering for complex mul, > fma and fms > > ping > > > -----Original Message----- > > From: Tamar Christina > > Sent: Monday, December 20, 2021 4:21 PM > > To: Richard Sandiford <richard.sandiford@arm.com> > > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com>; Richard Earnshaw > > <Richard.Earnshaw@arm.com>; Marcus Shawcroft > > <Marcus.Shawcroft@arm.com>; Kyrylo Tkachov > <Kyrylo.Tkachov@arm.com> > > Subject: RE: [2/3 PATCH]AArch64 use canonical ordering for complex > > mul, fma and fms > > > > > > > > > -----Original Message----- > > > From: Richard Sandiford <richard.sandiford@arm.com> > > > Sent: Friday, December 17, 2021 4:49 PM > > > To: Tamar Christina <Tamar.Christina@arm.com> > > > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com>; Richard Earnshaw > > > <Richard.Earnshaw@arm.com>; Marcus Shawcroft > > > <Marcus.Shawcroft@arm.com>; Kyrylo Tkachov > > <Kyrylo.Tkachov@arm.com> > > > Subject: Re: [2/3 PATCH]AArch64 use canonical ordering for complex > > > mul, fma and fms > > > > > > Richard Sandiford <richard.sandiford@arm.com> writes: > > > > Tamar Christina <tamar.christina@arm.com> writes: > > > >> Hi All, > > > >> > > > >> After the first patch in the series this updates the optabs to > > > >> expect the canonical sequence. > > > >> > > > >> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > > >> > > > >> Ok for master? and backport along with the first patch? > > > >> > > > >> Thanks, > > > >> Tamar > > > >> > > > >> gcc/ChangeLog: > > > >> > > > >> PR tree-optimization/102819 > > > >> PR tree-optimization/103169 > > > >> * config/aarch64/aarch64-simd.md > > > (cml<fcmac1><conj_op><mode>4, > > > >> cmul<conj_op><mode>3): Use canonical order. > > > >> * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4, > > > >> cmul<conj_op><mode>3): Likewise. > > > >> > > > >> --- inline copy of patch -- > > > >> diff --git a/gcc/config/aarch64/aarch64-simd.md > > > >> b/gcc/config/aarch64/aarch64-simd.md > > > >> index > > > >> > > > > > > f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..875896ee71324712c8034eeff9 > > > c > > > >> fb5649f9b0e73 100644 > > > >> --- a/gcc/config/aarch64/aarch64-simd.md > > > >> +++ b/gcc/config/aarch64/aarch64-simd.md > > > >> @@ -556,17 +556,17 @@ (define_insn > > > "aarch64_fcmlaq_lane<rot><mode>" > > > >> ;; remainder. Because of this, expand early. > > > >> (define_expand "cml<fcmac1><conj_op><mode>4" > > > >> [(set (match_operand:VHSDF 0 "register_operand") > > > >> - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") > > > >> - (unspec:VHSDF [(match_operand:VHSDF 2 > > > "register_operand") > > > >> - (match_operand:VHSDF 3 > > > "register_operand")] > > > >> - FCMLA_OP)))] > > > >> + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 > > > "register_operand") > > > >> + (match_operand:VHSDF 2 > > > "register_operand")] > > > >> + FCMLA_OP) > > > >> + (match_operand:VHSDF 3 "register_operand")))] > > > >> "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" > > > >> { > > > >> rtx tmp = gen_reg_rtx (<MODE>mode); > > > >> - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, > operands[1], > > > >> - operands[3], operands[2])); > > > >> + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, > operands[3], > > > >> + operands[1], > operands[2])); > > > >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], > tmp, > > > >> - operands[3], operands[2])); > > > >> + operands[1], > operands[2])); > > > >> DONE; > > > >> }) > > > >> > > > >> @@ -583,9 +583,9 @@ (define_expand "cmul<conj_op><mode>3" > > > >> rtx tmp = force_reg (<MODE>mode, CONST0_RTX (<MODE>mode)); > > > >> rtx res1 = gen_reg_rtx (<MODE>mode); > > > >> emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (res1, tmp, > > > >> - operands[2], operands[1])); > > > >> + operands[1], > operands[2])); > > > >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], > res1, > > > >> - operands[2], operands[1])); > > > >> + operands[1], > operands[2])); > > > > > > > > This doesn't look right. Going from the documentation, patch 1 > > > > isn't changing the operand order for CMUL: the conjugated operand > > > > (if there is one) is still operand 2. The FCMLA sequences use the > > > > opposite order, where the conjugated operand (if there is one) is > > operand 1. > > > > So I think > > > > > > I meant “the first multiplication operand” rather than “operand 1” here. > > > > > > > the reversal here is still needed. > > > > > > > > Same for the multiplication operands in CML* above. > > > > I did actually change the order in patch 1, but didn't update the docs.. > > That was done because I followed the SLP order again, but now I've > > updated them to do what the docs say. > > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > > > Ok for master? and backport along with the first patch? > > > > Thanks, > > Tamar > > > > gcc/ChangeLog: > > > > PR tree-optimization/102819 > > PR tree-optimization/103169 > > * config/aarch64/aarch64-simd.md > > (cml<fcmac1><conj_op><mode>4): Use > > canonical order. > > * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4): > > Likewise. > > > > --- inline copy of patch --- > > > > diff --git a/gcc/config/aarch64/aarch64-simd.md > > b/gcc/config/aarch64/aarch64-simd.md > > index > > > f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..9e41610fba85862ef7675bea1 > > e5731b14cab59ce 100644 > > --- a/gcc/config/aarch64/aarch64-simd.md > > +++ b/gcc/config/aarch64/aarch64-simd.md > > @@ -556,17 +556,17 @@ (define_insn > "aarch64_fcmlaq_lane<rot><mode>" > > ;; remainder. Because of this, expand early. > > (define_expand "cml<fcmac1><conj_op><mode>4" > > [(set (match_operand:VHSDF 0 "register_operand") > > - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") > > - (unspec:VHSDF [(match_operand:VHSDF 2 > > "register_operand") > > - (match_operand:VHSDF 3 > > "register_operand")] > > - FCMLA_OP)))] > > + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 > > "register_operand") > > + (match_operand:VHSDF 2 > > "register_operand")] > > + FCMLA_OP) > > + (match_operand:VHSDF 3 "register_operand")))] > > "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" > > { > > rtx tmp = gen_reg_rtx (<MODE>mode); > > - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], > > - operands[3], operands[2])); > > + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], > > + operands[2], operands[1])); > > emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, > > - operands[3], operands[2])); > > + operands[2], operands[1])); > > DONE; > > }) > > > > diff --git a/gcc/config/aarch64/aarch64-sve.md > > b/gcc/config/aarch64/aarch64-sve.md > > index > > > 9ef968840c20a3049901b3f8a919cf27ded1da3e..9ed19017c480b88779e9e3b08 > > c0e031be60a8c12 100644 > > --- a/gcc/config/aarch64/aarch64-sve.md > > +++ b/gcc/config/aarch64/aarch64-sve.md > > @@ -7278,11 +7278,11 @@ (define_expand > "cml<fcmac1><conj_op><mode>4" > > rtx tmp = gen_reg_rtx (<MODE>mode); > > emit_insn > > (gen_aarch64_pred_fcmla<sve_rot1><mode> (tmp, operands[4], > > - operands[3], operands[2], > > - operands[1], operands[5])); > > + operands[2], operands[1], > > + operands[3], operands[5])); > > emit_insn > > (gen_aarch64_pred_fcmla<sve_rot2><mode> (operands[0], > operands[4], > > - operands[3], operands[2], > > + operands[2], operands[1], > > tmp, operands[5])); > > DONE; > > })
Tamar Christina <Tamar.Christina@arm.com> writes: >> -----Original Message----- >> From: Richard Sandiford <richard.sandiford@arm.com> >> Sent: Friday, December 17, 2021 4:49 PM >> To: Tamar Christina <Tamar.Christina@arm.com> >> Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com>; Richard Earnshaw >> <Richard.Earnshaw@arm.com>; Marcus Shawcroft >> <Marcus.Shawcroft@arm.com>; Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> >> Subject: Re: [2/3 PATCH]AArch64 use canonical ordering for complex mul, >> fma and fms >> >> Richard Sandiford <richard.sandiford@arm.com> writes: >> > Tamar Christina <tamar.christina@arm.com> writes: >> >> Hi All, >> >> >> >> After the first patch in the series this updates the optabs to expect >> >> the canonical sequence. >> >> >> >> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >> >> >> >> Ok for master? and backport along with the first patch? >> >> >> >> Thanks, >> >> Tamar >> >> >> >> gcc/ChangeLog: >> >> >> >> PR tree-optimization/102819 >> >> PR tree-optimization/103169 >> >> * config/aarch64/aarch64-simd.md >> (cml<fcmac1><conj_op><mode>4, >> >> cmul<conj_op><mode>3): Use canonical order. >> >> * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4, >> >> cmul<conj_op><mode>3): Likewise. >> >> >> >> --- inline copy of patch -- >> >> diff --git a/gcc/config/aarch64/aarch64-simd.md >> >> b/gcc/config/aarch64/aarch64-simd.md >> >> index >> >> >> f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..875896ee71324712c8034eeff9 >> c >> >> fb5649f9b0e73 100644 >> >> --- a/gcc/config/aarch64/aarch64-simd.md >> >> +++ b/gcc/config/aarch64/aarch64-simd.md >> >> @@ -556,17 +556,17 @@ (define_insn >> "aarch64_fcmlaq_lane<rot><mode>" >> >> ;; remainder. Because of this, expand early. >> >> (define_expand "cml<fcmac1><conj_op><mode>4" >> >> [(set (match_operand:VHSDF 0 "register_operand") >> >> - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") >> >> - (unspec:VHSDF [(match_operand:VHSDF 2 >> "register_operand") >> >> - (match_operand:VHSDF 3 >> "register_operand")] >> >> - FCMLA_OP)))] >> >> + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 >> "register_operand") >> >> + (match_operand:VHSDF 2 >> "register_operand")] >> >> + FCMLA_OP) >> >> + (match_operand:VHSDF 3 "register_operand")))] >> >> "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" >> >> { >> >> rtx tmp = gen_reg_rtx (<MODE>mode); >> >> - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], >> >> - operands[3], operands[2])); >> >> + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], >> >> + operands[1], operands[2])); >> >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, >> >> - operands[3], operands[2])); >> >> + operands[1], operands[2])); >> >> DONE; >> >> }) >> >> >> >> @@ -583,9 +583,9 @@ (define_expand "cmul<conj_op><mode>3" >> >> rtx tmp = force_reg (<MODE>mode, CONST0_RTX (<MODE>mode)); >> >> rtx res1 = gen_reg_rtx (<MODE>mode); >> >> emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (res1, tmp, >> >> - operands[2], operands[1])); >> >> + operands[1], operands[2])); >> >> emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], res1, >> >> - operands[2], operands[1])); >> >> + operands[1], operands[2])); >> > >> > This doesn't look right. Going from the documentation, patch 1 isn't >> > changing the operand order for CMUL: the conjugated operand (if there >> > is one) is still operand 2. The FCMLA sequences use the opposite >> > order, where the conjugated operand (if there is one) is operand 1. >> > So I think >> >> I meant “the first multiplication operand” rather than “operand 1” here. >> >> > the reversal here is still needed. >> > >> > Same for the multiplication operands in CML* above. > > I did actually change the order in patch 1, but didn't update the docs.. > That was done because I followed the SLP order again, but now I've updated > them to do what the docs say. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? and backport along with the first patch? OK, thanks. Richard > Thanks, > Tamar > > gcc/ChangeLog: > > PR tree-optimization/102819 > PR tree-optimization/103169 > * config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4): Use > canonical order. > * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4): Likewise. > > --- inline copy of patch --- > > diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md > index f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..9e41610fba85862ef7675bea1e5731b14cab59ce 100644 > --- a/gcc/config/aarch64/aarch64-simd.md > +++ b/gcc/config/aarch64/aarch64-simd.md > @@ -556,17 +556,17 @@ (define_insn "aarch64_fcmlaq_lane<rot><mode>" > ;; remainder. Because of this, expand early. > (define_expand "cml<fcmac1><conj_op><mode>4" > [(set (match_operand:VHSDF 0 "register_operand") > - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") > - (unspec:VHSDF [(match_operand:VHSDF 2 "register_operand") > - (match_operand:VHSDF 3 "register_operand")] > - FCMLA_OP)))] > + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 "register_operand") > + (match_operand:VHSDF 2 "register_operand")] > + FCMLA_OP) > + (match_operand:VHSDF 3 "register_operand")))] > "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" > { > rtx tmp = gen_reg_rtx (<MODE>mode); > - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], > - operands[3], operands[2])); > + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], > + operands[2], operands[1])); > emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, > - operands[3], operands[2])); > + operands[2], operands[1])); > DONE; > }) > > diff --git a/gcc/config/aarch64/aarch64-sve.md b/gcc/config/aarch64/aarch64-sve.md > index 9ef968840c20a3049901b3f8a919cf27ded1da3e..9ed19017c480b88779e9e3b08c0e031be60a8c12 100644 > --- a/gcc/config/aarch64/aarch64-sve.md > +++ b/gcc/config/aarch64/aarch64-sve.md > @@ -7278,11 +7278,11 @@ (define_expand "cml<fcmac1><conj_op><mode>4" > rtx tmp = gen_reg_rtx (<MODE>mode); > emit_insn > (gen_aarch64_pred_fcmla<sve_rot1><mode> (tmp, operands[4], > - operands[3], operands[2], > - operands[1], operands[5])); > + operands[2], operands[1], > + operands[3], operands[5])); > emit_insn > (gen_aarch64_pred_fcmla<sve_rot2><mode> (operands[0], operands[4], > - operands[3], operands[2], > + operands[2], operands[1], > tmp, operands[5])); > DONE; > })
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..875896ee71324712c8034eeff9cfb5649f9b0e73 100644 --- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -556,17 +556,17 @@ (define_insn "aarch64_fcmlaq_lane<rot><mode>" ;; remainder. Because of this, expand early. (define_expand "cml<fcmac1><conj_op><mode>4" [(set (match_operand:VHSDF 0 "register_operand") - (plus:VHSDF (match_operand:VHSDF 1 "register_operand") - (unspec:VHSDF [(match_operand:VHSDF 2 "register_operand") - (match_operand:VHSDF 3 "register_operand")] - FCMLA_OP)))] + (plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 "register_operand") + (match_operand:VHSDF 2 "register_operand")] + FCMLA_OP) + (match_operand:VHSDF 3 "register_operand")))] "TARGET_COMPLEX && !BYTES_BIG_ENDIAN" { rtx tmp = gen_reg_rtx (<MODE>mode); - emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1], - operands[3], operands[2])); + emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3], + operands[1], operands[2])); emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp, - operands[3], operands[2])); + operands[1], operands[2])); DONE; }) @@ -583,9 +583,9 @@ (define_expand "cmul<conj_op><mode>3" rtx tmp = force_reg (<MODE>mode, CONST0_RTX (<MODE>mode)); rtx res1 = gen_reg_rtx (<MODE>mode); emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (res1, tmp, - operands[2], operands[1])); + operands[1], operands[2])); emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], res1, - operands[2], operands[1])); + operands[1], operands[2])); DONE; }) diff --git a/gcc/config/aarch64/aarch64-sve.md b/gcc/config/aarch64/aarch64-sve.md index 9ef968840c20a3049901b3f8a919cf27ded1da3e..96a57442c7eb5f1080c8014a2f0311b2350de852 100644 --- a/gcc/config/aarch64/aarch64-sve.md +++ b/gcc/config/aarch64/aarch64-sve.md @@ -7278,11 +7278,11 @@ (define_expand "cml<fcmac1><conj_op><mode>4" rtx tmp = gen_reg_rtx (<MODE>mode); emit_insn (gen_aarch64_pred_fcmla<sve_rot1><mode> (tmp, operands[4], - operands[3], operands[2], - operands[1], operands[5])); + operands[1], operands[2], + operands[3], operands[5])); emit_insn (gen_aarch64_pred_fcmla<sve_rot2><mode> (operands[0], operands[4], - operands[3], operands[2], + operands[1], operands[2], tmp, operands[5])); DONE; }) @@ -7305,11 +7305,11 @@ (define_expand "cmul<conj_op><mode>3" rtx tmp = gen_reg_rtx (<MODE>mode); emit_insn (gen_aarch64_pred_fcmla<sve_rot1><mode> (tmp, pred_reg, - operands[2], operands[1], + operands[1], operands[2], accum, gp_mode)); emit_insn (gen_aarch64_pred_fcmla<sve_rot2><mode> (operands[0], pred_reg, - operands[2], operands[1], + operands[1], operands[2], tmp, gp_mode)); DONE; })