Message ID | ZhjwwAw4+PTOvPii@arm.com |
---|---|
State | New |
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 139703858C39 for <patchwork@sourceware.org>; Fri, 12 Apr 2024 08:30:48 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on2044.outbound.protection.outlook.com [40.107.15.44]) by sourceware.org (Postfix) with ESMTPS id 607853858D38 for <gcc-patches@gcc.gnu.org>; Fri, 12 Apr 2024 08:29:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 607853858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 607853858D38 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.15.44 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1712910555; cv=pass; b=eVhY6WqXq6vNGm1SM93TdSesj03/oci0vHsgkurkuWplDVCxoQKVCH+ioaMQzsmdROWEmePg5mjr/VBI7iu8JbpkMUkpleS4KSn2jeToy43MoWa6atX9ltSwP/1Fxddf8bQq2LsoVIrxxOPINBSGgFlFUoIp+kMFCg6o8MAvaIs= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1712910555; c=relaxed/simple; bh=ZZkzHppzf+LUta6+7z7dRIqST5irD4hrKPqXqLq0wCc=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=lKT8kU5EX12tqry2B9Yd4xdh1ok6LVVNodW/oDcwU/ylsb5C32SqKSCoG/nSLA9uJEMt3Bjgg0Ue91rtube22mt4rdfDQIFh24618XocH+bF94st/GRq/r+4jLDV9d2JuuiKEOU9Rx85juIbU9Qs4tx7jAtf4eTXZhQ2EgqgfkQ= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=fFa6+Y8k5SKE/6x6RbGiEYL63bdeqEOwpTTk96ON5I3/ht4mwe7xoCyCm7NaBJB+xYLDqkrAoct7Fx7pwyima3I/nRw4lb+fn4/G5GS/UKNjl1JGuGMPPzGRdxmuxRhR2eDlxvCfNUnc6Clb504iCTPkFdeizBs1bOLh1iEfsxDgHHWvc1E1Iz1uMNcwjwoBNaorGtw4agCVsRMAqoxEkClYccC+QyB+VCqKZPQjSous18QUVFdeV8MM56xn2+E1WlCn15oRBmaHbQRdC+StPcOnPnKtxUZMyHz/2XqMF18Z/89A64nQJX3srLF9xBpYBRKsCG8VgIBxMdgg221XPA== ARC-Message-Signature: i=2; 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=ecq/5jTQBKobb10Z9UUFIIkgkw8Ynbl1R3v/H1KEHPo=; b=FVbluc/YnnceWM+o7XP1KC0tEbm+6d4Pf7rKT2hgfiYYajKD8rnnPg6fZAbHgaDfy4wIW6z+NCHy81fW2c8uocNlrhj2TCQ7xSD5gXE7BaxCrIPaWFypXYiR7Vc0Q5xkpQdGGX7xTLRH1HeoNd1Yflf2l4+0BPnVkV0PdoEJwiaTIfVipG/aiBLpZinQ2dqTViEuVXFJlQah3bIVdl6c2gl5KF4Rd4JQWoubSayfrRLfejhGX3kFl2KC1YiQdAM2H2CJxC8xyfv5bNksKmP5b8JNmUqJjXi6Lxrczy6fq3GT8k4mmwXqZG/HeaXgu+wbFgGDwO5LGJyMnhY53x28gw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=gcc.gnu.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ecq/5jTQBKobb10Z9UUFIIkgkw8Ynbl1R3v/H1KEHPo=; b=mc30MyAPWI2J1RZAxi0TWtW+rfb8wlTRD+bklR9Vwmm8HdX5h/mVICe84uJDrUzb2G93Ydxp+WfMWQN4oEQdrPVHOjE+TgNBVsdp0ar8+WzqmTBjtquyCs5BIjuB66OgWRpRE9i0GZisiA3qZ3tLF6slx7ikuAfzLgKebtE9tYk= Received: from DUZPR01CA0140.eurprd01.prod.exchangelabs.com (2603:10a6:10:4bd::23) by AS8PR08MB9621.eurprd08.prod.outlook.com (2603:10a6:20b:61a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.46; Fri, 12 Apr 2024 08:29:03 +0000 Received: from DU6PEPF00009528.eurprd02.prod.outlook.com (2603:10a6:10:4bd:cafe::e8) by DUZPR01CA0140.outlook.office365.com (2603:10a6:10:4bd::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7472.26 via Frontend Transport; Fri, 12 Apr 2024 08:29:03 +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 DU6PEPF00009528.mail.protection.outlook.com (10.167.8.9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7452.22 via Frontend Transport; Fri, 12 Apr 2024 08:29:03 +0000 Received: ("Tessian outbound dad50f1992f6:v300"); Fri, 12 Apr 2024 08:29:02 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 2076aa975a760af7 X-CR-MTA-TID: 64aa7808 Received: from 1108e7b7c074.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A9BC6BAF-7D74-4C61-A6BD-BA1368865FA5.1; Fri, 12 Apr 2024 08:28:56 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1108e7b7c074.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Apr 2024 08:28:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R17jXsTndYvcCEBo+qSg6Dtd9fTEgnQIewq5Mtd/nOr6U3sYX7Gb5XgGlmSjYHsT7gGftWi6QsAPhmomytc2ZmReMX92dRS1vJK+jDJKZusIjJFUhsFkOkiTr012ZHIZ8n11b1GSEcj91gGsr/JiFjPd5PyIz7TFVc8yvkD4ORzkTlVfxCq6fthVtzdhVQ1XwFYcNX3tQ04tGn6iRK3IUZ6nDv0kwIMsQy4Q84oqqNh7RUt+vJaXcEftejop/EOLXSmlyxhQ2oB0rG7vqrxH1JZz6Pj565aLUOVdsP1ofzT1F7OMSyT+nDJUKGYGzcmFhVHEMXkHe6B4nrsRJ7jjzQ== 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=ecq/5jTQBKobb10Z9UUFIIkgkw8Ynbl1R3v/H1KEHPo=; b=BUvzThMY7EU1zWe09o/UGccBHK4XKKZvdVpeTd/zk/5JymKwEoN8UM5+gU1ItkxH0p94QYwAS2iN9vY9ByipHNlvDJXfodTlJD9AxMUgZ0iASdEzLQB3HSLTlK0VT2nFEShKgWu2PFn9sefJPExXn89S43AlvIwhbqiEeXHUlUxT6IkBEV96cWDVXsLrnGHM0gwQxTPLQEwrPL/18RjRsml7cGRh27hiK4heRYY8KCtXJN6r6uQ8nlM3DIFtq5sqFYTB1KPUZJITwp8CLg2hDcSpY8BmNyqHfkUXdrZ1BrYtwXv6iIUTBezotR5asQvn94SFIXlqCayZ5T0TMGgCaQ== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ecq/5jTQBKobb10Z9UUFIIkgkw8Ynbl1R3v/H1KEHPo=; b=mc30MyAPWI2J1RZAxi0TWtW+rfb8wlTRD+bklR9Vwmm8HdX5h/mVICe84uJDrUzb2G93Ydxp+WfMWQN4oEQdrPVHOjE+TgNBVsdp0ar8+WzqmTBjtquyCs5BIjuB66OgWRpRE9i0GZisiA3qZ3tLF6slx7ikuAfzLgKebtE9tYk= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from PAWPR08MB8958.eurprd08.prod.outlook.com (2603:10a6:102:33e::15) by AM8PR08MB5713.eurprd08.prod.outlook.com (2603:10a6:20b:1dc::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.46; Fri, 12 Apr 2024 08:28:52 +0000 Received: from PAWPR08MB8958.eurprd08.prod.outlook.com ([fe80::9561:db03:3f6c:5634]) by PAWPR08MB8958.eurprd08.prod.outlook.com ([fe80::9561:db03:3f6c:5634%5]) with mapi id 15.20.7409.042; Fri, 12 Apr 2024 08:28:51 +0000 Date: Fri, 12 Apr 2024 09:28:48 +0100 From: Alex Coplan <alex.coplan@arm.com> To: gcc-patches@gcc.gnu.org Cc: Richard Sandiford <richard.sandiford@arm.com> Subject: [PATCH v2] aarch64: Preserve mem info on change of base for ldp/stp [PR114674] Message-ID: <ZhjwwAw4+PTOvPii@arm.com> Content-Type: multipart/mixed; boundary="K8XHvEBvQGN+oSf5" Content-Disposition: inline X-ClientProxiedBy: LO4P265CA0204.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:318::14) To PAWPR08MB8958.eurprd08.prod.outlook.com (2603:10a6:102:33e::15) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: PAWPR08MB8958:EE_|AM8PR08MB5713:EE_|DU6PEPF00009528:EE_|AS8PR08MB9621:EE_ X-MS-Office365-Filtering-Correlation-Id: ae8b80fe-1842-4fca-335a-08dc5aca9c39 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: 5/Khg4B98m8HpsQ2vUc0/zabz0f6nyvC8PgLZwRCOTCaBuENhb5WbSHSgO2wfG7Cw4u7rYS/ueoFCiOb3WF6Qn7J/Ti3ety+Y1/5g0YK/AZ3WdyfyttK1bP1pe/0/gJdbdoZPukCVMCmXnzFyvnsGDxjQutSNPH3KpWrhhZlg1nKilzphtzzS4vAq+S0BkyC1Wo7SywP3hq4w/J4NfiTQWOlOTbtVOus7FQYulQQiaaCNihBo3u3KNFtD+5O3fFnOwbYgngO+7f0n8/nWqUqwKui/isNlZwPIQN49Jm7iibfdBFGSEs3hAG5k0grx5oQZ2cCctuw+GoQ/l3DS79VoMG8xlqAID7tz4+v+B7sF1isAfbWRlRhslrYTODJY1b6Q2Hb7Pc5PBFO1IjtIIkpeXgIl7ptvLzda2yRgeH4LZ+vWfkaDCBf8686UwD/JXptzEJBsc/QrLrM6jEUdBXxM+A+9TAdApL2ApAvdO0K80sEp7P4JU0EKg8JqicCjq0enzFhlKinwoxg/SY4DJaZQzT0iM04cwNGYtCeFgTLKwphXHdc5OJcpXTO+Vs/4ifZzi5Jsy/bCVmUglZm20QFwqc2v51qXDdwMNmf8Vbj51U= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PAWPR08MB8958.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366007)(1800799015)(376005); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5713 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: DU6PEPF00009528.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: fb5326eb-8931-481f-d317-08dc5aca94d0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: aHNEV3SOyI/WoA0a9qzBUHbvwpAOF75szSeEBVo7KuQmjHhbK+nqmBitCR+RbBbBg4GOlYaukY7yuzMa67plWw86TBUF1qXw/KyJVlBK9zlG96EmixUx00muwCga439OSEmFgWovyg5kLmLc3E54lZ6Qj5cUX32zNXEZAWa2U8dMod57ZT4A3ffP/LO1wIuO9A/r3dWvBN3yk/yeKcvAf4wmCV0UNW8hx2E5PqpKe1GQhr9ffbAS2+KaKRdGFNddlpqwCPjVXtdnLYIpGADMyxp0n6ABSG5E4yG9dJlrgM8XGW+noG3jfG8X74ZF92bYrQnQVoPXq2kxH0pOk34LD0rb2T6jAEQ5+6MpgmgxDfiHI4GIyrXefCrXJPkpN42kUS8z7/OBPFIZtjL5jHmtr6UAdjsQ8GjhSqZTiEnk6oDR4Xih7apgB0j5MYzo+DJ02SgqsYoZgrhwSRfPTzyZ6fKFLrz++BXwKaPXmw7q506rVf7dO9bglQsGIXFwhAQSyfQiGTOr9OPVal8uryyNtrEyrOtxEZiz3/keywsQod984goOvRBO2SeBkeAVVkK4ZpYMDs0Awy2CJ4rgZx3bZ72EjRT1VWhNIQLUpRM1t4VI6VjEBKOVtDgvoEMMc6DUc+dEcrOOgjm+wY52F835TLeLfo1tVW9XKJnVRWrfV18cM8WRgiCJ82/zK7f+vSXHDc8/23SJjI1fw1MeyIzTkA== 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:(13230031)(36860700004)(82310400014)(376005)(1800799015); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2024 08:29:03.0499 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ae8b80fe-1842-4fca-335a-08dc5aca9c39 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: DU6PEPF00009528.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9621 X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, KAM_SHORT, 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.30 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> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org |
Series |
[v2] aarch64: Preserve mem info on change of base for ldp/stp [PR114674]
|
|
Checks
Context | Check | Description |
---|---|---|
linaro-tcwg-bot/tcwg_gcc_build--master-arm | success | Testing passed |
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 | success | Testing passed |
linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 | success | Testing passed |
linaro-tcwg-bot/tcwg_gcc_check--master-arm | success | Testing passed |
Commit Message
Alex Coplan
April 12, 2024, 8:28 a.m. UTC
This is a v2 because I accidentally sent a WIP version of the patch last time round which used replace_equiv_address instead of replace_equiv_address_nv; that caused some ICEs (pointed out by the Linaro CI) since pair addressing modes aren't a subset of the addresses that are accepted by memory_operand for a given mode. This patch should otherwise be identical to v1. Bootstrapped/regtested on aarch64-linux-gnu (indeed this is the patch I actually tested last time), is this version also OK for GCC 15? Thanks, Alex --- >8 --- The ldp/stp fusion pass can change the base of an access so that the two accesses end up using a common base register. So far we have been using adjust_address_nv to do this, but this means that we don't preserve other properties of the mem we're replacing. It seems better to use replace_equiv_address_nv, as this will preserve e.g. the MEM_ALIGN of the mem whose address we're changing. The PR shows that by adjusting the other mem we lose alignment information about the original access and therefore end up rejecting an otherwise viable pair when --param=aarch64-stp-policy=aligned is passed. This patch fixes that by using replace_equiv_address_nv instead. Notably this is the same approach as taken by aarch64_check_consecutive_mems when a change of base is required, so this at least makes things more consistent between the ldp fusion pass and the peepholes. gcc/ChangeLog: PR target/114674 * config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair): Use replace_equiv_address_nv on a change of base instead of adjust_address_nv on the other access. gcc/testsuite/ChangeLog: PR target/114674 * gcc.target/aarch64/pr114674.c: New test.
Comments
Alex Coplan <alex.coplan@arm.com> writes: > This is a v2 because I accidentally sent a WIP version of the patch last > time round which used replace_equiv_address instead of > replace_equiv_address_nv; that caused some ICEs (pointed out by the > Linaro CI) since pair addressing modes aren't a subset of the addresses > that are accepted by memory_operand for a given mode. > > This patch should otherwise be identical to v1. Bootstrapped/regtested > on aarch64-linux-gnu (indeed this is the patch I actually tested last > time), is this version also OK for GCC 15? OK, thanks. Sorry for missing this in the first review. Richard > Thanks, > Alex > > --- >8 --- > > The ldp/stp fusion pass can change the base of an access so that the two > accesses end up using a common base register. So far we have been using > adjust_address_nv to do this, but this means that we don't preserve > other properties of the mem we're replacing. It seems better to use > replace_equiv_address_nv, as this will preserve e.g. the MEM_ALIGN of the > mem whose address we're changing. > > The PR shows that by adjusting the other mem we lose alignment > information about the original access and therefore end up rejecting an > otherwise viable pair when --param=aarch64-stp-policy=aligned is passed. > This patch fixes that by using replace_equiv_address_nv instead. > > Notably this is the same approach as taken by > aarch64_check_consecutive_mems when a change of base is required, so > this at least makes things more consistent between the ldp fusion pass > and the peepholes. > > gcc/ChangeLog: > > PR target/114674 > * config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair): > Use replace_equiv_address_nv on a change of base instead of > adjust_address_nv on the other access. > > gcc/testsuite/ChangeLog: > > PR target/114674 > * gcc.target/aarch64/pr114674.c: New test. > > diff --git a/gcc/config/aarch64/aarch64-ldp-fusion.cc b/gcc/config/aarch64/aarch64-ldp-fusion.cc > index 365dcf48b22..d07d79df06c 100644 > --- a/gcc/config/aarch64/aarch64-ldp-fusion.cc > +++ b/gcc/config/aarch64/aarch64-ldp-fusion.cc > @@ -1730,11 +1730,11 @@ ldp_bb_info::fuse_pair (bool load_p, > adjust_amt *= -1; > > rtx change_reg = XEXP (change_pat, !load_p); > - machine_mode mode_for_mem = GET_MODE (change_mem); > rtx effective_base = drop_writeback (base_mem); > - rtx new_mem = adjust_address_nv (effective_base, > - mode_for_mem, > - adjust_amt); > + rtx adjusted_addr = plus_constant (Pmode, > + XEXP (effective_base, 0), > + adjust_amt); > + rtx new_mem = replace_equiv_address_nv (change_mem, adjusted_addr); > rtx new_set = load_p > ? gen_rtx_SET (change_reg, new_mem) > : gen_rtx_SET (new_mem, change_reg); > diff --git a/gcc/testsuite/gcc.target/aarch64/pr114674.c b/gcc/testsuite/gcc.target/aarch64/pr114674.c > new file mode 100644 > index 00000000000..944784fd008 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/aarch64/pr114674.c > @@ -0,0 +1,17 @@ > +/* { dg-do compile } */ > +/* { dg-options "-O3 --param=aarch64-stp-policy=aligned" } */ > +typedef struct { > + unsigned int f1; > + unsigned int f2; > +} test_struct; > + > +static test_struct ts = { > + 123, 456 > +}; > + > +void foo(void) > +{ > + ts.f2 = 36969 * (ts.f2 & 65535) + (ts.f1 >> 16); > + ts.f1 = 18000 * (ts.f2 & 65535) + (ts.f2 >> 16); > +} > +/* { dg-final { scan-assembler-times "stp" 1 } } */
On 12/04/2024 12:13, Richard Sandiford wrote: > Alex Coplan <alex.coplan@arm.com> writes: > > This is a v2 because I accidentally sent a WIP version of the patch last > > time round which used replace_equiv_address instead of > > replace_equiv_address_nv; that caused some ICEs (pointed out by the > > Linaro CI) since pair addressing modes aren't a subset of the addresses > > that are accepted by memory_operand for a given mode. > > > > This patch should otherwise be identical to v1. Bootstrapped/regtested > > on aarch64-linux-gnu (indeed this is the patch I actually tested last > > time), is this version also OK for GCC 15? > > OK, thanks. Sorry for missing this in the first review. Now pushed to trunk, thanks. Alex > > Richard > > > Thanks, > > Alex > > > > --- >8 --- > > > > The ldp/stp fusion pass can change the base of an access so that the two > > accesses end up using a common base register. So far we have been using > > adjust_address_nv to do this, but this means that we don't preserve > > other properties of the mem we're replacing. It seems better to use > > replace_equiv_address_nv, as this will preserve e.g. the MEM_ALIGN of the > > mem whose address we're changing. > > > > The PR shows that by adjusting the other mem we lose alignment > > information about the original access and therefore end up rejecting an > > otherwise viable pair when --param=aarch64-stp-policy=aligned is passed. > > This patch fixes that by using replace_equiv_address_nv instead. > > > > Notably this is the same approach as taken by > > aarch64_check_consecutive_mems when a change of base is required, so > > this at least makes things more consistent between the ldp fusion pass > > and the peepholes. > > > > gcc/ChangeLog: > > > > PR target/114674 > > * config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair): > > Use replace_equiv_address_nv on a change of base instead of > > adjust_address_nv on the other access. > > > > gcc/testsuite/ChangeLog: > > > > PR target/114674 > > * gcc.target/aarch64/pr114674.c: New test. > > > > diff --git a/gcc/config/aarch64/aarch64-ldp-fusion.cc b/gcc/config/aarch64/aarch64-ldp-fusion.cc > > index 365dcf48b22..d07d79df06c 100644 > > --- a/gcc/config/aarch64/aarch64-ldp-fusion.cc > > +++ b/gcc/config/aarch64/aarch64-ldp-fusion.cc > > @@ -1730,11 +1730,11 @@ ldp_bb_info::fuse_pair (bool load_p, > > adjust_amt *= -1; > > > > rtx change_reg = XEXP (change_pat, !load_p); > > - machine_mode mode_for_mem = GET_MODE (change_mem); > > rtx effective_base = drop_writeback (base_mem); > > - rtx new_mem = adjust_address_nv (effective_base, > > - mode_for_mem, > > - adjust_amt); > > + rtx adjusted_addr = plus_constant (Pmode, > > + XEXP (effective_base, 0), > > + adjust_amt); > > + rtx new_mem = replace_equiv_address_nv (change_mem, adjusted_addr); > > rtx new_set = load_p > > ? gen_rtx_SET (change_reg, new_mem) > > : gen_rtx_SET (new_mem, change_reg); > > diff --git a/gcc/testsuite/gcc.target/aarch64/pr114674.c b/gcc/testsuite/gcc.target/aarch64/pr114674.c > > new file mode 100644 > > index 00000000000..944784fd008 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/aarch64/pr114674.c > > @@ -0,0 +1,17 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-O3 --param=aarch64-stp-policy=aligned" } */ > > +typedef struct { > > + unsigned int f1; > > + unsigned int f2; > > +} test_struct; > > + > > +static test_struct ts = { > > + 123, 456 > > +}; > > + > > +void foo(void) > > +{ > > + ts.f2 = 36969 * (ts.f2 & 65535) + (ts.f1 >> 16); > > + ts.f1 = 18000 * (ts.f2 & 65535) + (ts.f2 >> 16); > > +} > > +/* { dg-final { scan-assembler-times "stp" 1 } } */
diff --git a/gcc/config/aarch64/aarch64-ldp-fusion.cc b/gcc/config/aarch64/aarch64-ldp-fusion.cc index 365dcf48b22..d07d79df06c 100644 --- a/gcc/config/aarch64/aarch64-ldp-fusion.cc +++ b/gcc/config/aarch64/aarch64-ldp-fusion.cc @@ -1730,11 +1730,11 @@ ldp_bb_info::fuse_pair (bool load_p, adjust_amt *= -1; rtx change_reg = XEXP (change_pat, !load_p); - machine_mode mode_for_mem = GET_MODE (change_mem); rtx effective_base = drop_writeback (base_mem); - rtx new_mem = adjust_address_nv (effective_base, - mode_for_mem, - adjust_amt); + rtx adjusted_addr = plus_constant (Pmode, + XEXP (effective_base, 0), + adjust_amt); + rtx new_mem = replace_equiv_address_nv (change_mem, adjusted_addr); rtx new_set = load_p ? gen_rtx_SET (change_reg, new_mem) : gen_rtx_SET (new_mem, change_reg); diff --git a/gcc/testsuite/gcc.target/aarch64/pr114674.c b/gcc/testsuite/gcc.target/aarch64/pr114674.c new file mode 100644 index 00000000000..944784fd008 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/pr114674.c @@ -0,0 +1,17 @@ +/* { dg-do compile } */ +/* { dg-options "-O3 --param=aarch64-stp-policy=aligned" } */ +typedef struct { + unsigned int f1; + unsigned int f2; +} test_struct; + +static test_struct ts = { + 123, 456 +}; + +void foo(void) +{ + ts.f2 = 36969 * (ts.f2 & 65535) + (ts.f1 >> 16); + ts.f1 = 18000 * (ts.f2 & 65535) + (ts.f2 >> 16); +} +/* { dg-final { scan-assembler-times "stp" 1 } } */