Message ID | patch-16595-tamar@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 61E963893653 for <patchwork@sourceware.org>; Tue, 15 Nov 2022 10:34:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 61E963893653 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668508475; bh=+Z0W2quQTVXZXKYlDRQ0VEP8GMBbdS7sDZXhc14AG2g=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=WpXh4+rMOhMU5FW7HGwHINszcgp4B5fZOOHP1A2SQBpBAtB8RtU0OyDjfBLCOsdzf vx2GUc7pYF3gcPFFxbyim899cYSjWJaLh3iYpF6s5QYE1+O+5eDBPOtr0QFKohazGy ThJGuEAT6bxDFIJlWaXSaCDFXmqHPusCjjeNrb3A= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60062.outbound.protection.outlook.com [40.107.6.62]) by sourceware.org (Postfix) with ESMTPS id CDB37388B68D for <gcc-patches@gcc.gnu.org>; Tue, 15 Nov 2022 10:34:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CDB37388B68D Received: from AS9PR06CA0717.eurprd06.prod.outlook.com (2603:10a6:20b:49f::28) by DBBPR08MB6010.eurprd08.prod.outlook.com (2603:10a6:10:20a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.12; Tue, 15 Nov 2022 10:34:00 +0000 Received: from VI1EUR03FT005.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:49f:cafe::1e) by AS9PR06CA0717.outlook.office365.com (2603:10a6:20b:49f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.17 via Frontend Transport; Tue, 15 Nov 2022 10:34:00 +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; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VI1EUR03FT005.mail.protection.outlook.com (100.127.144.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.12 via Frontend Transport; Tue, 15 Nov 2022 10:34:00 +0000 Received: ("Tessian outbound 0800d254cb3b:v130"); Tue, 15 Nov 2022 10:33:59 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: f745d815e8d22657 X-CR-MTA-TID: 64aa7808 Received: from 53378998defd.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 98C93F98-56DB-46FB-AA5E-3F7F93E9590F.1; Tue, 15 Nov 2022 10:33:52 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 53378998defd.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 15 Nov 2022 10:33:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gBqyzx8KzJ+I1yrZYsVm9vlDk6B2zOW9yDaJMb3YLF4rlfMfmUtrU7F+G0+ZIT1659L6s7sg9nARVtrZAZI+qZ+/qORR8Eqos5hfv1MRKEgOL9M74Cto7yc2BZYLRGC9heVaGlrDK6m9gqtU6UWTEa4iKAJUS0a8FG5T/u0tg2/kbrXa3dQALy4QbUYzXnK16Z225M+UZlpvnRw3lQ/dzrzlTiVtbPPapk3hNva/VqKV1tqf+IobR8zJAlXm3f5PmwbmaWTwxK42r7fafMpkRwRa41F5PLIsTTziFQgMU8gQzp6to5eRWIqhXyYYXCO/z0HILe3ICu4YSqgT4iSSew== 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=+Z0W2quQTVXZXKYlDRQ0VEP8GMBbdS7sDZXhc14AG2g=; b=n9yfjjXoUA1McnvImxA7a2m83ifci4/gV0iM8CPHrFWgM3m6C3LjPD/joA1vkp55CFUaKRjdjSa9O7fo1aUyMAem9XNLOu+vfeHbEbFAiqjNUjLpuKyFY+0qxmyBI2MSxX10xuRp5oniVKgGgC0W3+6o0rYivLa0MzZTqpHu7N6W2tmw+5Kk/3gDXzf6xcMjMniXza4n04LV9TdLSJxKLElwFmqxrWD9FXJmQSDMjVdDQTHKPSfG8thYODciuaovJlRnR9zYSyAA6LPr3SNUX8b7DLiMnRUYS8TEV/E0EWi5nObkEQk/FV8LUeVp0iqQ1JDxomo3zsaoauBynNbxUQ== 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 DB9PR08MB6746.eurprd08.prod.outlook.com (2603:10a6:10:2a0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5834.6; Tue, 15 Nov 2022 10:33:40 +0000 Received: from VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::bd2a:aff9:b1a0:2fc7]) by VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::bd2a:aff9:b1a0:2fc7%4]) with mapi id 15.20.5834.007; Tue, 15 Nov 2022 10:33:40 +0000 Date: Tue, 15 Nov 2022 10:33:36 +0000 To: gcc-patches@gcc.gnu.org Cc: nd@arm.com, rguenther@suse.de, jlaw@ventanamicro.com Subject: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with GET_MODE_NEXT_MODE Message-ID: <patch-16595-tamar@arm.com> Content-Type: multipart/mixed; boundary="LbI2R1rXZrGIY7OJ" Content-Disposition: inline X-ClientProxiedBy: LO2P265CA0248.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::20) To VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB5325:EE_|DB9PR08MB6746:EE_|VI1EUR03FT005:EE_|DBBPR08MB6010:EE_ X-MS-Office365-Filtering-Correlation-Id: aa30c9d5-80c8-4f65-19b9-08dac6f4e894 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: xfI2SIwLvnBa8bSKmRXSN1omtUbwLeNTg1he2lsJiOZYuhJiO5jJWiUy5Wi/Om+AYDmfqlzCKdh5aNkfdNREfzdceI+6hO08pnwkIfStL+pOpxogXDPAu0zQVgWpguDPHLxqc9Nrjlc9vdHkUjllAPkb1wdZkkcz+qCLlBDGG8d30zmkbWD7mvYBprUKv1G+TN9NcbHugevo4UDtOloLFhwnHG3Ttm9oY4B7NXTHTJn5jzlgWvXw9zQNipWcrj1bbKlZDW/9suBK83L9e4Kalc5tsBK8R1Y/J0Hliol8VdatmHxLYTm1uB7CcO0mTHDdB0DYHIRXeYGAIdH72iUiud4wRl9E0bGjCTcm65sSSqZL1y8rryBecCbWVZXwdmgwznIgQlNcZktQkBGdBAckoCgHE6LzRj+rQxfN8YuNh575jzkj+8WZUhtzWg1C79XidxpsecKpmPNU1qkjzb9Mgzh824xhSesPlYuI2njyWpV1VyKYqjEBSw2NC2e/DLvwgZw6/Bj0dCvr2/jpWTX/K+D6aWSZT20MVijYeJeu0pAK1eiKTrEWaJ7UwKjbvLkarYigLDPJvP7i3BN3kXWN4sqyVil1ZH+YS7Mh15oDb4LCk5kyLiZyg3WMJ5Wxy+gHHTxuxK4U96ytdOiLyYgEYw98Xd1QGLY3GXLtA1lIVZ4JJTWg7q6Hs5gRqRqlISWGiwqc9OzCit09kd9KMuGUlZiDlfz54Q45rRiNpyxyjcdiVCFyCCsIpSGriZ4C3VJaf91hatrrngUEmby8avyg3lzRaaMPQeSIcXhZBiCxma8= 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:(13230022)(4636009)(366004)(376002)(396003)(346002)(136003)(39860400002)(451199015)(6506007)(4743002)(6512007)(41300700001)(6666004)(2906002)(86362001)(26005)(6916009)(478600001)(5660300002)(235185007)(6486002)(186003)(316002)(4326008)(8936002)(2616005)(44832011)(38100700002)(66556008)(66476007)(66946007)(8676002)(36756003)(44144004)(33964004)(4216001)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6746 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: VI1EUR03FT005.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 3279e694-4f35-483d-7786-08dac6f4dcbb X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mTkfIA/GdiO6K8wKMb0/BIgTvuPxsS3yiWF4vbOJU6fCulBmQ100Aj9Q86xgQEK7h3yh52TEDchxyi/YcnBX3NCbQnQjcxTv1bGNHUktOpSnrp+ov8lgIKtgGwPa/ZUE3k4Jc7sc2M1WTAM+3wBm8hZAfBv2WBP+1ITJj0FG5PHmwcMs99OPdRX9fxvxCBfaJ+dLASfsmZ2oNCPqOslt9Vv7HO+MuYeDm9WCnuJfs1xxiYOWV8/mm9ZVXBPypHzuvxE6saM3lKu3v/a7Q1JrOUtjb8WFgICGlZeq4yFSpDDdV4D9oZ4UQTpE/RBZaZUxlgJ0rEg8Gs/T02K4rjMnh7hWcOKMEoeySstJQwEYOCSYkpOfGz3yAeFJLh3BzYjkS9chq8q2AkgkO8CmfgttSt9OiljFdpn9yA81GYbljmQ68td/wwJvhlictQcWceqBbZz5Xu1zTXHurJ9eDHweq2TLnndVcIYWc9Se90usrrT5nXtV8UFF/nwkdFEE460LZWpKqMYOMy1CLvqXi2VYp795ZpmkeFvDDa69aIUK5a/ELQX69WgiAUz3yUToRiMzvZk69AXMHSOFJVfb81rKwNk+t+zEC6VAoqb/xqgVqit+kvpqJG/iC2yQexB25IBA3C9gO+AQgNkVcLNUXrtJywUelosaqRFSDtqDbUvSJcBk+JMNc3E6Lcs6RKhka/B4Gnu9GlfiNXSkEcK6a6kHorhIZyvrAzDOYIbQoLbjvVd+u4cOEKuFplNk5S99zYSjjNN0IumjfFpxrVS+t08hdoGly8iR4lHjS0HTTT2xeBXgxG3A62DwtnnhULmR3sMW+CVZWMiL+heKOVbc8WyAEQ== 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:(13230022)(4636009)(396003)(376002)(346002)(136003)(39860400002)(451199015)(46966006)(40470700004)(36840700001)(36756003)(41300700001)(47076005)(4326008)(356005)(81166007)(8676002)(86362001)(40480700001)(82310400005)(4743002)(478600001)(336012)(2616005)(107886003)(316002)(6666004)(6486002)(82740400003)(26005)(186003)(8936002)(70586007)(5660300002)(36860700001)(40460700003)(70206006)(6512007)(6916009)(44832011)(2906002)(44144004)(33964004)(235185007)(6506007)(4216001)(2700100001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2022 10:34:00.1436 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aa30c9d5-80c8-4f65-19b9-08dac6f4e894 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: VI1EUR03FT005.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6010 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
middle-end: replace GET_MODE_WIDER_MODE with GET_MODE_NEXT_MODE
|
|
Commit Message
Tamar Christina
Nov. 15, 2022, 10:33 a.m. UTC
Hi All, After the fix to the addsub patch yesterday for bootstrap I had only regtested on x86. While looking today it seemed the new tests were failing, this was caused by a change in the behavior of the GET_MODE_WIDER_MODE macro on trunk. This patch fixes that issue. Sorry for the mess, have rebased all branches now. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? Thanks, Tamar gcc/ChangeLog: * match.pd: Replace GET_MODE_WIDER_MODE with GET_MODE_NEXT_MODE. --- inline copy of patch -- diff --git a/gcc/match.pd b/gcc/match.pd index 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..28191a992039c6f3a1dab5f7c0e35dd58dc47092 100644 -- diff --git a/gcc/match.pd b/gcc/match.pd index 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..28191a992039c6f3a1dab5f7c0e35dd58dc47092 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -7997,7 +7997,7 @@ and, machine_mode wide_mode; } (if (sel.series_p (0, 2, 0, 2) - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) + && GET_MODE_NEXT_MODE (vec_mode).exists (&wide_mode) && VECTOR_MODE_P (wide_mode) && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 == GET_MODE_UNIT_BITSIZE (wide_mode)))
Comments
Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > Hi All, > > After the fix to the addsub patch yesterday for bootstrap I had only regtested on x86. > While looking today it seemed the new tests were failing, this was caused > by a change in the behavior of the GET_MODE_WIDER_MODE macro on trunk. > > This patch fixes that issue. Sorry for the mess, have rebased all branches now. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? > > Thanks, > Tamar > > gcc/ChangeLog: > > * match.pd: Replace GET_MODE_WIDER_MODE with > GET_MODE_NEXT_MODE. > > --- inline copy of patch -- > diff --git a/gcc/match.pd b/gcc/match.pd > index 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..28191a992039c6f3a1dab5f7c0e35dd58dc47092 100644 > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -7997,7 +7997,7 @@ and, > machine_mode wide_mode; > } > (if (sel.series_p (0, 2, 0, 2) > - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) > + && GET_MODE_NEXT_MODE (vec_mode).exists (&wide_mode) > && VECTOR_MODE_P (wide_mode) > && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 > == GET_MODE_UNIT_BITSIZE (wide_mode))) Does anything guarantee that the next mode will be the right one? It think it would be safer to replace the last three && conditions with: && GET_MODE_2XWIDER_MODE (GET_MODE_INNER (vec_mode)).exists (&wide_elt_mode) && multiple_p (GET_MODE_NUNITS (vec_mode), 2, &wide_nunits) && related_vector_mode (vec_mode, wide_elt_mode, wide_nunits).exists (&wide_mode) Thanks, Richard
> -----Original Message----- > From: Richard Sandiford <richard.sandiford@arm.com> > Sent: Tuesday, November 15, 2022 11:59 AM > To: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> > Cc: Tamar Christina <Tamar.Christina@arm.com>; nd <nd@arm.com>; > rguenther@suse.de; jlaw@ventanamicro.com > Subject: Re: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with > GET_MODE_NEXT_MODE > > Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > > Hi All, > > > > After the fix to the addsub patch yesterday for bootstrap I had only > regtested on x86. > > While looking today it seemed the new tests were failing, this was > > caused by a change in the behavior of the GET_MODE_WIDER_MODE > macro on trunk. > > > > This patch fixes that issue. Sorry for the mess, have rebased all branches > now. > > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > > > Ok for master? > > > > Thanks, > > Tamar > > > > gcc/ChangeLog: > > > > * match.pd: Replace GET_MODE_WIDER_MODE with > > GET_MODE_NEXT_MODE. > > > > --- inline copy of patch -- > > diff --git a/gcc/match.pd b/gcc/match.pd index > > > 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..28191a992039c6f3a1dab5f7c0 > e3 > > 5dd58dc47092 100644 > > --- a/gcc/match.pd > > +++ b/gcc/match.pd > > @@ -7997,7 +7997,7 @@ and, > > machine_mode wide_mode; > > } > > (if (sel.series_p (0, 2, 0, 2) > > - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) > > + && GET_MODE_NEXT_MODE (vec_mode).exists (&wide_mode) > > && VECTOR_MODE_P (wide_mode) > > && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 > > == GET_MODE_UNIT_BITSIZE (wide_mode))) > > Does anything guarantee that the next mode will be the right one? > It think it would be safer to replace the last three && conditions with: > > && GET_MODE_2XWIDER_MODE (GET_MODE_INNER (vec_mode)).exists > (&wide_elt_mode) > && multiple_p (GET_MODE_NUNITS (vec_mode), 2, &wide_nunits) > && related_vector_mode (vec_mode, wide_elt_mode, > wide_nunits).exists (&wide_mode) I see, respun patch accordingly. Ok for master? --- inline copy of patch --- diff --git a/gcc/match.pd b/gcc/match.pd index 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..82f05bbc912e4f80f3984d930c4a8dcb010136e1 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -7995,12 +7995,15 @@ and, vec_perm_indices sel (builder, 2, nelts); machine_mode vec_mode = TYPE_MODE (type); machine_mode wide_mode; + scalar_mode wide_elt_mode; + poly_uint64 wide_nunits; + scalar_mode inner_mode = GET_MODE_INNER (vec_mode); } (if (sel.series_p (0, 2, 0, 2) - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) - && VECTOR_MODE_P (wide_mode) - && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 - == GET_MODE_UNIT_BITSIZE (wide_mode))) + && GET_MODE_2XWIDER_MODE (inner_mode).exists (&wide_elt_mode) + && multiple_p (GET_MODE_NUNITS (vec_mode), 2, &wide_nunits) + && related_vector_mode (vec_mode, wide_elt_mode, + wide_nunits).exists (&wide_mode)) (with { tree stype
Tamar Christina <Tamar.Christina@arm.com> writes: >> -----Original Message----- >> From: Richard Sandiford <richard.sandiford@arm.com> >> Sent: Tuesday, November 15, 2022 11:59 AM >> To: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> >> Cc: Tamar Christina <Tamar.Christina@arm.com>; nd <nd@arm.com>; >> rguenther@suse.de; jlaw@ventanamicro.com >> Subject: Re: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with >> GET_MODE_NEXT_MODE >> >> Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> > Hi All, >> > >> > After the fix to the addsub patch yesterday for bootstrap I had only >> regtested on x86. >> > While looking today it seemed the new tests were failing, this was >> > caused by a change in the behavior of the GET_MODE_WIDER_MODE >> macro on trunk. >> > >> > This patch fixes that issue. Sorry for the mess, have rebased all branches >> now. >> > >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >> > >> > Ok for master? >> > >> > Thanks, >> > Tamar >> > >> > gcc/ChangeLog: >> > >> > * match.pd: Replace GET_MODE_WIDER_MODE with >> > GET_MODE_NEXT_MODE. >> > >> > --- inline copy of patch -- >> > diff --git a/gcc/match.pd b/gcc/match.pd index >> > >> 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..28191a992039c6f3a1dab5f7c0 >> e3 >> > 5dd58dc47092 100644 >> > --- a/gcc/match.pd >> > +++ b/gcc/match.pd >> > @@ -7997,7 +7997,7 @@ and, >> > machine_mode wide_mode; >> > } >> > (if (sel.series_p (0, 2, 0, 2) >> > - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) >> > + && GET_MODE_NEXT_MODE (vec_mode).exists (&wide_mode) >> > && VECTOR_MODE_P (wide_mode) >> > && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 >> > == GET_MODE_UNIT_BITSIZE (wide_mode))) >> >> Does anything guarantee that the next mode will be the right one? >> It think it would be safer to replace the last three && conditions with: >> >> && GET_MODE_2XWIDER_MODE (GET_MODE_INNER (vec_mode)).exists >> (&wide_elt_mode) >> && multiple_p (GET_MODE_NUNITS (vec_mode), 2, &wide_nunits) >> && related_vector_mode (vec_mode, wide_elt_mode, >> wide_nunits).exists (&wide_mode) > > I see, respun patch accordingly. LGTM, but I'm nervous when it comes to match.pd stuff so I'd prefer Richi or Jeff to have the final say. Thanks, Richard > > Ok for master? > > --- inline copy of patch --- > > diff --git a/gcc/match.pd b/gcc/match.pd > index 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..82f05bbc912e4f80f3984d930c4a8dcb010136e1 100644 > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -7995,12 +7995,15 @@ and, > vec_perm_indices sel (builder, 2, nelts); > machine_mode vec_mode = TYPE_MODE (type); > machine_mode wide_mode; > + scalar_mode wide_elt_mode; > + poly_uint64 wide_nunits; > + scalar_mode inner_mode = GET_MODE_INNER (vec_mode); > } > (if (sel.series_p (0, 2, 0, 2) > - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) > - && VECTOR_MODE_P (wide_mode) > - && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 > - == GET_MODE_UNIT_BITSIZE (wide_mode))) > + && GET_MODE_2XWIDER_MODE (inner_mode).exists (&wide_elt_mode) > + && multiple_p (GET_MODE_NUNITS (vec_mode), 2, &wide_nunits) > + && related_vector_mode (vec_mode, wide_elt_mode, > + wide_nunits).exists (&wide_mode)) > (with > { > tree stype
On 11/15/22 07:54, Richard Sandiford via Gcc-patches wrote: > Tamar Christina <Tamar.Christina@arm.com> writes: >>> -----Original Message----- >>> From: Richard Sandiford <richard.sandiford@arm.com> >>> Sent: Tuesday, November 15, 2022 11:59 AM >>> To: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> >>> Cc: Tamar Christina <Tamar.Christina@arm.com>; nd <nd@arm.com>; >>> rguenther@suse.de; jlaw@ventanamicro.com >>> Subject: Re: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with >>> GET_MODE_NEXT_MODE >>> >>> Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >>>> Hi All, >>>> >>>> After the fix to the addsub patch yesterday for bootstrap I had only >>> regtested on x86. >>>> While looking today it seemed the new tests were failing, this was >>>> caused by a change in the behavior of the GET_MODE_WIDER_MODE >>> macro on trunk. >>>> This patch fixes that issue. Sorry for the mess, have rebased all branches >>> now. >>>> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >>>> >>>> Ok for master? >>>> >>>> Thanks, >>>> Tamar >>>> >>>> gcc/ChangeLog: >>>> >>>> * match.pd: Replace GET_MODE_WIDER_MODE with >>>> GET_MODE_NEXT_MODE. >>>> >>>> --- inline copy of patch -- >>>> diff --git a/gcc/match.pd b/gcc/match.pd index >>>> >>> 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..28191a992039c6f3a1dab5f7c0 >>> e3 >>>> 5dd58dc47092 100644 >>>> --- a/gcc/match.pd >>>> +++ b/gcc/match.pd >>>> @@ -7997,7 +7997,7 @@ and, >>>> machine_mode wide_mode; >>>> } >>>> (if (sel.series_p (0, 2, 0, 2) >>>> - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) >>>> + && GET_MODE_NEXT_MODE (vec_mode).exists (&wide_mode) >>>> && VECTOR_MODE_P (wide_mode) >>>> && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 >>>> == GET_MODE_UNIT_BITSIZE (wide_mode))) >>> Does anything guarantee that the next mode will be the right one? >>> It think it would be safer to replace the last three && conditions with: >>> >>> && GET_MODE_2XWIDER_MODE (GET_MODE_INNER (vec_mode)).exists >>> (&wide_elt_mode) >>> && multiple_p (GET_MODE_NUNITS (vec_mode), 2, &wide_nunits) >>> && related_vector_mode (vec_mode, wide_elt_mode, >>> wide_nunits).exists (&wide_mode) >> I see, respun patch accordingly. > LGTM, but I'm nervous when it comes to match.pd stuff so I'd prefer > Richi or Jeff to have the final say. It's just a matter of finding that 2X wider mode to make the transformation possible. So I don't see any concerns here. jeff
On Tue, 15 Nov 2022, Richard Sandiford wrote: > Tamar Christina <Tamar.Christina@arm.com> writes: > >> -----Original Message----- > >> From: Richard Sandiford <richard.sandiford@arm.com> > >> Sent: Tuesday, November 15, 2022 11:59 AM > >> To: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> > >> Cc: Tamar Christina <Tamar.Christina@arm.com>; nd <nd@arm.com>; > >> rguenther@suse.de; jlaw@ventanamicro.com > >> Subject: Re: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with > >> GET_MODE_NEXT_MODE > >> > >> Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > >> > Hi All, > >> > > >> > After the fix to the addsub patch yesterday for bootstrap I had only > >> regtested on x86. > >> > While looking today it seemed the new tests were failing, this was > >> > caused by a change in the behavior of the GET_MODE_WIDER_MODE > >> macro on trunk. > >> > > >> > This patch fixes that issue. Sorry for the mess, have rebased all branches > >> now. > >> > > >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > >> > > >> > Ok for master? > >> > > >> > Thanks, > >> > Tamar > >> > > >> > gcc/ChangeLog: > >> > > >> > * match.pd: Replace GET_MODE_WIDER_MODE with > >> > GET_MODE_NEXT_MODE. > >> > > >> > --- inline copy of patch -- > >> > diff --git a/gcc/match.pd b/gcc/match.pd index > >> > > >> 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..28191a992039c6f3a1dab5f7c0 > >> e3 > >> > 5dd58dc47092 100644 > >> > --- a/gcc/match.pd > >> > +++ b/gcc/match.pd > >> > @@ -7997,7 +7997,7 @@ and, > >> > machine_mode wide_mode; > >> > } > >> > (if (sel.series_p (0, 2, 0, 2) > >> > - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) > >> > + && GET_MODE_NEXT_MODE (vec_mode).exists (&wide_mode) > >> > && VECTOR_MODE_P (wide_mode) > >> > && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 > >> > == GET_MODE_UNIT_BITSIZE (wide_mode))) > >> > >> Does anything guarantee that the next mode will be the right one? > >> It think it would be safer to replace the last three && conditions with: > >> > >> && GET_MODE_2XWIDER_MODE (GET_MODE_INNER (vec_mode)).exists > >> (&wide_elt_mode) > >> && multiple_p (GET_MODE_NUNITS (vec_mode), 2, &wide_nunits) > >> && related_vector_mode (vec_mode, wide_elt_mode, > >> wide_nunits).exists (&wide_mode) > > > > I see, respun patch accordingly. > > LGTM, but I'm nervous when it comes to match.pd stuff so I'd prefer > Richi or Jeff to have the final say. I see nothing wrong here, so OK. Richard. > Thanks, > Richard > > > > > Ok for master? > > > > --- inline copy of patch --- > > > > diff --git a/gcc/match.pd b/gcc/match.pd > > index 1b0ab7cf60fa4772fbe8304c622b0b8fab1bdefa..82f05bbc912e4f80f3984d930c4a8dcb010136e1 100644 > > --- a/gcc/match.pd > > +++ b/gcc/match.pd > > @@ -7995,12 +7995,15 @@ and, > > vec_perm_indices sel (builder, 2, nelts); > > machine_mode vec_mode = TYPE_MODE (type); > > machine_mode wide_mode; > > + scalar_mode wide_elt_mode; > > + poly_uint64 wide_nunits; > > + scalar_mode inner_mode = GET_MODE_INNER (vec_mode); > > } > > (if (sel.series_p (0, 2, 0, 2) > > - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) > > - && VECTOR_MODE_P (wide_mode) > > - && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 > > - == GET_MODE_UNIT_BITSIZE (wide_mode))) > > + && GET_MODE_2XWIDER_MODE (inner_mode).exists (&wide_elt_mode) > > + && multiple_p (GET_MODE_NUNITS (vec_mode), 2, &wide_nunits) > > + && related_vector_mode (vec_mode, wide_elt_mode, > > + wide_nunits).exists (&wide_mode)) > > (with > > { > > tree stype >
--- a/gcc/match.pd +++ b/gcc/match.pd @@ -7997,7 +7997,7 @@ and, machine_mode wide_mode; } (if (sel.series_p (0, 2, 0, 2) - && GET_MODE_WIDER_MODE (vec_mode).exists (&wide_mode) + && GET_MODE_NEXT_MODE (vec_mode).exists (&wide_mode) && VECTOR_MODE_P (wide_mode) && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2 == GET_MODE_UNIT_BITSIZE (wide_mode)))