Message ID | patch-15911-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 3045D385735A for <patchwork@sourceware.org>; Tue, 5 Jul 2022 15:01:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3045D385735A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1657033292; bh=6QC6Z+nl2+r2XtKSiLFS2I2fliV+lsl3iBF80oD9cS4=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=D5tJzhi5iCgIrFxLip9wJWmzEOq+kncbNjKGqACIz02aM0d+BQSHFi4O0mrkasjKw hm6u86yRd5m4Ivk2udl/BXUG3K7n6RdXyuAZL/Zk2OWcQ4ysErm1Ik0PREsaQAw+O+ hcF0kQbE1BG07AWUu2AVcz7iTK6TS4wGJYSFZQPU= 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-eopbgr140077.outbound.protection.outlook.com [40.107.14.77]) by sourceware.org (Postfix) with ESMTPS id 2CD4D3858292 for <gcc-patches@gcc.gnu.org>; Tue, 5 Jul 2022 15:01:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2CD4D3858292 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=ewAXw1/It1YEXfJSqAr/B0xmbJ1avqNGEvOhUeLrS6x+ML47Pw5XsU5BpqsbVmBWYpasPjqM+Bn3dyhq7Vg1RMttkTx023fd0jmseCo2hbwWBwMHPq0SzN8WelUESKveSudEZF829Cw5YIpjXx8A6rVlCaLtIdjvojxy37Ps9seabUXcF0vQmnYcPcbo6BOa+9B6J8Sz4O3RFqAE2Ni6xFgxwe1E53KuRqw9pL8VzFALDMBgBHVlVKsIu3f9JFU24Z1wNyIUKQMroaXJnbQ9B5otyWF7s+hEhgyyvqhbHCkbBwOD26/rR2HC8sCDpxSN1yYe4jYYDTVjIWMut0y1Gg== 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=6QC6Z+nl2+r2XtKSiLFS2I2fliV+lsl3iBF80oD9cS4=; b=VXfVs9f/BftDv3c0u8VbW8EgFb6BUiVYmedWGz5aJC4Hpp/mYil8S88rvjoHmOs5mondqvRRXrJAM9SIYJZPTSxwifzU+rZdskk4LxYreOM34zWlBsrfRG2y1H5g8Av1uq3cyJzDPkr3tOTRg54NpnAmnGXK6e87BhK/zRis5joJmpfplHBkv7rEjvHwHTpMYm+qA4VngyClPDSm7zvhS5VqQ1wGdj23ljAjfHWlw/iniTox9//XsQ1AHJH9MWxsitPloL3Sd9ajAZ8KtwyeWMIO8wuKgW6/Dl+4RoQQNm0LkpsutywbGZ2Tbuu/i20yNk+cuZ1gYX/aiAJ1LAluEw== 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]) Received: from AM6PR02CA0022.eurprd02.prod.outlook.com (2603:10a6:20b:6e::35) by AM0PR08MB4482.eurprd08.prod.outlook.com (2603:10a6:208:140::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5395.14; Tue, 5 Jul 2022 15:00:57 +0000 Received: from VE1EUR03FT059.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:6e:cafe::b8) by AM6PR02CA0022.outlook.office365.com (2603:10a6:20b:6e::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5395.21 via Frontend Transport; Tue, 5 Jul 2022 15:00:57 +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 VE1EUR03FT059.mail.protection.outlook.com (10.152.19.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5395.14 via Frontend Transport; Tue, 5 Jul 2022 15:00:56 +0000 Received: ("Tessian outbound d5fa056a5959:v121"); Tue, 05 Jul 2022 15:00:56 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 5a5916d9f2275572 X-CR-MTA-TID: 64aa7808 Received: from a540dd0379ff.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 36B1738E-8568-49A1-852F-4C9F3B03C4C1.1; Tue, 05 Jul 2022 15:00:49 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a540dd0379ff.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 05 Jul 2022 15:00:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BWSZknmEIrjzgzf7Lth24O1CLLNdOY+wVZJV0AjFOqPutsRU1J5LANgtuc3eOjy+n+R0Lk75IyLcvU6BzcrwMi31DB3XseC6vEulSVYjq8NSfreOynOQ+Sn7nwDTpu5yIzwq20X6r/NxTbT7txzoJDR1AfAw+XNipVrwQ9q78AirRv3bVMqsZwIrW039l1y5Ft0q6Pn5ZUnvMRu1L54oUwjvpVU6EVe6yzUzN+P9EdXeUhifPbFoIzSVdyqYnXDsiJ7o429YUGJkGzDIJr0Tta9aB4R5ikZMr3ZoJAdKm/Wto2wNxKmxgXeE7jYTEITKPbaEVH0P5lR634gQOT50Pg== 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=6QC6Z+nl2+r2XtKSiLFS2I2fliV+lsl3iBF80oD9cS4=; b=WB6gw1qkxj/hQGmIJpMDo2Iyl1hkkOw72805DrXZxYrRRR5o/TMkUwMNH+hSm0yovC1Cp21Y2lHwX80wQsa3B9VFvS5JLWSG99D/tZhN/EmuXzKoIJIEhJhIjCv7wcgVYgUrzzCVLuoYjXVj2yz1+HzmUt2KhM5ll8JHyL0o8hEiT6Y+mPLvQwpa0bI2eMxAuW7JigaVY+0Hg5abC+vOSUnfvdZ2jtLh2qZIkhYGHFjw5pBKPmyyN9m6frZoM6TjdeKJMKVplic9b0fi0xvwqbjpqMo38hHYKzfNkABKoo0cdL+kv4XhN4Uob1dovP4HFv6ldPZ3oIvAQhw8gbAaVQ== 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 DBBPR08MB6204.eurprd08.prod.outlook.com (2603:10a6:10:1f5::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5395.15; Tue, 5 Jul 2022 15:00:48 +0000 Received: from VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::54e5:594b:e5fd:a9b4]) by VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::54e5:594b:e5fd:a9b4%9]) with mapi id 15.20.5395.021; Tue, 5 Jul 2022 15:00:48 +0000 Date: Tue, 5 Jul 2022 16:00:45 +0100 To: gcc-patches@gcc.gnu.org Subject: [PATCH]middle-end: don't lower past veclower [PR106063] Message-ID: <patch-15911-tamar@arm.com> Content-Type: multipart/mixed; boundary="Nw06EfYXcUJ04M0j" Content-Disposition: inline X-ClientProxiedBy: LO4P123CA0241.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a7::12) To VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 7a9a1722-3002-446f-6bef-08da5e972a3d X-MS-TrafficTypeDiagnostic: DBBPR08MB6204:EE_|VE1EUR03FT059:EE_|AM0PR08MB4482:EE_ 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: qqDqfhfhbYBwgA9w0q/t8TDYlN6qJwGIXkG/xQIBPIGsrhMKP4RYAPk84wuC/IIVXq8bkJ78GYE+U83Rr+efuDraRSYuNKoqm7VNkiu5FsZ1DUgttyixdDPVSpz0IHX0wqfunezzpOfn38Tl6tN5Mcga0gxoWj0c1IAQegEG2ZAPrwJhL79omuPHCT0Q+xXI1Ro3J3oseurX6+S17hzOhnCadbnhZahxr9i6uGCCD5FCklk9Pmibfwiect+iVkk5pd1gWLF8OMaTjsMW79p0pMLoWCLFsNsBPwfikQ9gfRRIUaGmyVv5bsgK2zK38EgeLmZTHR8n/rTtEye6fHs0CQBeSUhXg3z2TFy1rbJOhaz12JKNsDlRqWmXgXaH0eOFgFvUo1vdXETTo6fmfNL8NSva/KDKE9pQA+nqUdDYXoFf4zkwlOH4fVuG6C/R/AKKOfYKMV3Y8oR/L9N6FreiV6xcbkeESbtCocJHbt45Li9D0PJciO+KrtXNRLaeFH8TFTopWC686iGE4uuiX31ncSKD6FYTjTUBSpLkeQsTeSgzEX2P/ffCXrS4Qe2Uh9bK7kGVO7C0CYp6C76hPKKAVnUgbg0P51FcbX+0W7nehQU4PCimFQjl1gVaKlnfGph4B+Zdgfp2T3dvQzJoA/eF5wkMrXMWKdfLONz1UeOP2XcQuMhmyr4FJ/cCG4sxYJISmXlUAU/rwDxFGRnfs7hB4u+X3IAJ3lwtlzZ0oi2tTMo2jI8r85xU8lwZ0vQDc7FK4AkLMyFyULXJp50Y/vfMzQsIE1goBdl2NG5/HlUl/5ICvrwdp25O5YtfoGOVoEYCSYNDeR0v3Ficz8HBCCJs5oqbg17FfNZrWG4rWjg0bqY5pHEUKK4wlz7h48fmDoHe 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:(13230016)(4636009)(396003)(366004)(346002)(376002)(39860400002)(136003)(316002)(6916009)(36756003)(6512007)(26005)(186003)(84970400001)(2616005)(6506007)(86362001)(2906002)(5660300002)(235185007)(44832011)(66556008)(66476007)(33964004)(38100700002)(44144004)(66946007)(8676002)(4326008)(6666004)(478600001)(6486002)(41300700001)(8936002)(4216001)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6204 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: VE1EUR03FT059.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 0c36a646-d3ec-4cac-4e0c-08da5e9724ea X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bkw4S2orryiMtAW7kFZUgmR7PXhn3Qb7E7BcNRf5Xgk63PCxP3u85htjthMPBJrDZrQg1UNX0K7LMcPIij6i4CW+t4H9Re+Iz63sf3egqFd4vs1sf+K9eCjIQPuJ7ERq+aVvZGHofpjz87byPQxW2BXu3ivCSDzTTYDAOnWwsxoYxiRjBypxVL6b5H8l+KHmec8BDcqXreFEKKpiczPS9aTAR4yhXN4quJ3eh1zzPtkxEHizzyLhnnG+1EUTFEgJxZ/55wk6rMM4BiHYg100l7eu+VQRYnMEkM3ixPlbDTqqoSlEGTTuErjIKDWyR0/xTc1mpa2Px30wRCGRuISUc0Kb9HTLqoWc4zJaM4hFpQCaWn0ICLDrs9WqFBBy4Dw34Xwel25EYrPpW1Jz845rOONZOVwKW1vedl1CAOZZ9iPu2XIrjjhUzIDH3TKaltpDbL5i+pnYRy74Lc0kCVT7XDR/RpZ+klQjWMMdss5wU6oCFRPH5txU2AWdnHwu4YmGw8gM0kP+rexlnPTKrsGUiEpsLDvCeXv0nD+zFUSXkMfqpfFezi9v0Xrb9xFg0dwYEZDXyIzzqXprfOc5TcJFxCK1cuuqGmBK+jKtA71ZsTlcyN8M8c8gA4uIswajF8diyVqNKm1JckYtkGcsWdO3LCqWvdhJ8yzs5V8KdMbIpa9v9XO1Yhuog9ayGtI1R9QR5FPY2uImCNmMI+Cj2BkHO8wNNloekN+4EH939EFFDLM2APq0zAToUvMDCew9i/wjaYIAcBjsbSmnTC5E3VZxKeq87gyp/1U20fP0GiknUApKfKjCcVL3nQ8kCCZqmLdtOXaxajz0AmzwpsgYqKK5fZWs9qAnNnCTfzU1JGjIVN8DmXF12CmKFFYX2zgzXP+JKZVzhg80f5zV4Hc2wRBcaA== 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:(13230016)(4636009)(39860400002)(376002)(136003)(346002)(396003)(40470700004)(46966006)(36840700001)(40460700003)(86362001)(36860700001)(81166007)(82740400003)(356005)(82310400005)(8936002)(478600001)(6486002)(2906002)(5660300002)(41300700001)(235185007)(6666004)(44832011)(316002)(6916009)(47076005)(4326008)(8676002)(70206006)(70586007)(186003)(336012)(40480700001)(26005)(44144004)(6506007)(33964004)(2616005)(6512007)(107886003)(36756003)(84970400001)(4216001)(2700100001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2022 15:00:56.6993 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7a9a1722-3002-446f-6bef-08da5e972a3d 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: VE1EUR03FT059.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4482 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, KAM_LOTSOFHASH, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, 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> Cc: nd@arm.com, rguenther@suse.de 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: don't lower past veclower [PR106063]
|
|
Commit Message
Tamar Christina
July 5, 2022, 3 p.m. UTC
Hi All, My previous patch can cause a problem if the pattern matches after veclower as it may replace the construct with a vector sequence which the target may not directly support. As such don't perform the rewriting if after veclower. Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and no issues. Ok for master? and backport to GCC 12? Thanks, Tamar gcc/ChangeLog: PR tree-optimization/106063 * match.pd: Do not apply pattern after veclower. gcc/testsuite/ChangeLog: PR tree-optimization/106063 * gcc.dg/pr106063.c: New test. --- inline copy of patch -- diff --git a/gcc/match.pd b/gcc/match.pd index 40c09bedadb89dabb6622559a8f69df5384e61fd..ba161892a98756c0278dc40fc377d7d0deaacbcf 100644 -- diff --git a/gcc/match.pd b/gcc/match.pd index 40c09bedadb89dabb6622559a8f69df5384e61fd..ba161892a98756c0278dc40fc377d7d0deaacbcf 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -6040,7 +6040,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (simplify (cmp (bit_and:c@2 @0 cst@1) integer_zerop) (with { tree csts = bitmask_inv_cst_vector_p (@1); } - (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2))) + (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)) + && optimize_vectors_before_lowering_p ()) (if (TYPE_UNSIGNED (TREE_TYPE (@1))) (icmp @0 { csts; }) (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); } diff --git a/gcc/testsuite/gcc.dg/pr106063.c b/gcc/testsuite/gcc.dg/pr106063.c new file mode 100644 index 0000000000000000000000000000000000000000..b23596724f6bb98c53af2dce77d31509bab10378 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr106063.c @@ -0,0 +1,9 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fno-tree-forwprop --disable-tree-evrp" } */ +typedef __int128 __attribute__((__vector_size__ (16))) V; + +V +foo (V v) +{ + return (v & (V){15}) == v; +}
Comments
On 7/5/2022 9:00 AM, Tamar Christina via Gcc-patches wrote: > Hi All, > > My previous patch can cause a problem if the pattern matches after veclower > as it may replace the construct with a vector sequence which the target may not > directly support. > > As such don't perform the rewriting if after veclower. > > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu > and no issues. > > Ok for master? and backport to GCC 12? > > Thanks, > Tamar > > > gcc/ChangeLog: > > PR tree-optimization/106063 > * match.pd: Do not apply pattern after veclower. > > gcc/testsuite/ChangeLog: > > PR tree-optimization/106063 > * gcc.dg/pr106063.c: New test. OK for both the trunk and gcc-12. jeff
On Tue, 5 Jul 2022, Tamar Christina wrote: > Hi All, > > My previous patch can cause a problem if the pattern matches after veclower > as it may replace the construct with a vector sequence which the target may not > directly support. > > As such don't perform the rewriting if after veclower. Note that when doing the rewriting before veclower to a variant not supported by the target can cause veclower to generate absymal code. In some cases we are very careful and try to at least preserve code supported by the target over transforming that into a variant not supported. That said, a better fix would be to check whether the target can perform the new comparison. Before veclower it would be OK to do the transform nevertheless in case it cannot do the original transform. Richard. > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu > and no issues. > > Ok for master? and backport to GCC 12? > > Thanks, > Tamar > > > gcc/ChangeLog: > > PR tree-optimization/106063 > * match.pd: Do not apply pattern after veclower. > > gcc/testsuite/ChangeLog: > > PR tree-optimization/106063 > * gcc.dg/pr106063.c: New test. > > --- inline copy of patch -- > diff --git a/gcc/match.pd b/gcc/match.pd > index 40c09bedadb89dabb6622559a8f69df5384e61fd..ba161892a98756c0278dc40fc377d7d0deaacbcf 100644 > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -6040,7 +6040,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > (simplify > (cmp (bit_and:c@2 @0 cst@1) integer_zerop) > (with { tree csts = bitmask_inv_cst_vector_p (@1); } > - (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2))) > + (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)) > + && optimize_vectors_before_lowering_p ()) > (if (TYPE_UNSIGNED (TREE_TYPE (@1))) > (icmp @0 { csts; }) > (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); } > diff --git a/gcc/testsuite/gcc.dg/pr106063.c b/gcc/testsuite/gcc.dg/pr106063.c > new file mode 100644 > index 0000000000000000000000000000000000000000..b23596724f6bb98c53af2dce77d31509bab10378 > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/pr106063.c > @@ -0,0 +1,9 @@ > +/* { dg-do compile } */ > +/* { dg-options "-O2 -fno-tree-forwprop --disable-tree-evrp" } */ > +typedef __int128 __attribute__((__vector_size__ (16))) V; > + > +V > +foo (V v) > +{ > + return (v & (V){15}) == v; > +} > > > > >
> -----Original Message----- > From: Richard Biener <rguenther@suse.de> > Sent: Thursday, July 7, 2022 8:19 AM > To: Tamar Christina <Tamar.Christina@arm.com> > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com> > Subject: Re: [PATCH]middle-end: don't lower past veclower [PR106063] > > On Tue, 5 Jul 2022, Tamar Christina wrote: > > > Hi All, > > > > My previous patch can cause a problem if the pattern matches after > > veclower as it may replace the construct with a vector sequence which > > the target may not directly support. > > > > As such don't perform the rewriting if after veclower. > > Note that when doing the rewriting before veclower to a variant not > supported by the target can cause veclower to generate absymal code. In > some cases we are very careful and try to at least preserve code supported > by the target over transforming that into a variant not supported. > > That said, a better fix would be to check whether the target can perform the > new comparison. Before veclower it would be OK to do the transform > nevertheless in case it cannot do the original transform. This last statement is somewhat confusing. Did you want me to change it such that before veclower the rewrite is always done and after veclowering only if the target supports it? Or did you want me to never do the rewrite if the target doesn't support it? Thanks, Tamar > > Richard. > > > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu > > and no issues. > > > > Ok for master? and backport to GCC 12? > > > > Thanks, > > Tamar > > > > > > gcc/ChangeLog: > > > > PR tree-optimization/106063 > > * match.pd: Do not apply pattern after veclower. > > > > gcc/testsuite/ChangeLog: > > > > PR tree-optimization/106063 > > * gcc.dg/pr106063.c: New test. > > > > --- inline copy of patch -- > > diff --git a/gcc/match.pd b/gcc/match.pd index > > > 40c09bedadb89dabb6622559a8f69df5384e61fd..ba161892a98756c0278dc40fc > 377 > > d7d0deaacbcf 100644 > > --- a/gcc/match.pd > > +++ b/gcc/match.pd > > @@ -6040,7 +6040,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > > (simplify > > (cmp (bit_and:c@2 @0 cst@1) integer_zerop) > > (with { tree csts = bitmask_inv_cst_vector_p (@1); } > > - (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2))) > > + (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)) > > + && optimize_vectors_before_lowering_p ()) > > (if (TYPE_UNSIGNED (TREE_TYPE (@1))) > > (icmp @0 { csts; }) > > (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); } > > diff --git a/gcc/testsuite/gcc.dg/pr106063.c > > b/gcc/testsuite/gcc.dg/pr106063.c new file mode 100644 index > > > 0000000000000000000000000000000000000000..b23596724f6bb98c53af2dce77 > d3 > > 1509bab10378 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.dg/pr106063.c > > @@ -0,0 +1,9 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-O2 -fno-tree-forwprop --disable-tree-evrp" } */ > > +typedef __int128 __attribute__((__vector_size__ (16))) V; > > + > > +V > > +foo (V v) > > +{ > > + return (v & (V){15}) == v; > > +} > > > > > > > > > > > > -- > Richard Biener <rguenther@suse.de> > SUSE Software Solutions Germany GmbH, Frankenstra
On Thu, 7 Jul 2022, Tamar Christina wrote: > > -----Original Message----- > > From: Richard Biener <rguenther@suse.de> > > Sent: Thursday, July 7, 2022 8:19 AM > > To: Tamar Christina <Tamar.Christina@arm.com> > > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com> > > Subject: Re: [PATCH]middle-end: don't lower past veclower [PR106063] > > > > On Tue, 5 Jul 2022, Tamar Christina wrote: > > > > > Hi All, > > > > > > My previous patch can cause a problem if the pattern matches after > > > veclower as it may replace the construct with a vector sequence which > > > the target may not directly support. > > > > > > As such don't perform the rewriting if after veclower. > > > > Note that when doing the rewriting before veclower to a variant not > > supported by the target can cause veclower to generate absymal code. In > > some cases we are very careful and try to at least preserve code supported > > by the target over transforming that into a variant not supported. > > > > That said, a better fix would be to check whether the target can perform the > > new comparison. Before veclower it would be OK to do the transform > > nevertheless in case it cannot do the original transform. > > This last statement is somewhat confusing. Did you want me to change it such that > before veclower the rewrite is always done and after veclowering only if the target > supports it? > > Or did you want me to never do the rewrite if the target doesn't support it? I meant before veclower you can do the rewrite if either the rewriting result is supported by the target OR if the original expression is _not_ supported by the target. The latter case might be not too important to worry doing (it would still canonicalize for those targets then). After veclower you can only rewrite under the former condition. Richard. > Thanks, > Tamar > > > > > Richard. > > > > > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu > > > and no issues. > > > > > > Ok for master? and backport to GCC 12? > > > > > > Thanks, > > > Tamar > > > > > > > > > gcc/ChangeLog: > > > > > > PR tree-optimization/106063 > > > * match.pd: Do not apply pattern after veclower. > > > > > > gcc/testsuite/ChangeLog: > > > > > > PR tree-optimization/106063 > > > * gcc.dg/pr106063.c: New test. > > > > > > --- inline copy of patch -- > > > diff --git a/gcc/match.pd b/gcc/match.pd index > > > > > 40c09bedadb89dabb6622559a8f69df5384e61fd..ba161892a98756c0278dc40fc > > 377 > > > d7d0deaacbcf 100644 > > > --- a/gcc/match.pd > > > +++ b/gcc/match.pd > > > @@ -6040,7 +6040,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > > > (simplify > > > (cmp (bit_and:c@2 @0 cst@1) integer_zerop) > > > (with { tree csts = bitmask_inv_cst_vector_p (@1); } > > > - (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2))) > > > + (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)) > > > + && optimize_vectors_before_lowering_p ()) > > > (if (TYPE_UNSIGNED (TREE_TYPE (@1))) > > > (icmp @0 { csts; }) > > > (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); } > > > diff --git a/gcc/testsuite/gcc.dg/pr106063.c > > > b/gcc/testsuite/gcc.dg/pr106063.c new file mode 100644 index > > > > > 0000000000000000000000000000000000000000..b23596724f6bb98c53af2dce77 > > d3 > > > 1509bab10378 > > > --- /dev/null > > > +++ b/gcc/testsuite/gcc.dg/pr106063.c > > > @@ -0,0 +1,9 @@ > > > +/* { dg-do compile } */ > > > +/* { dg-options "-O2 -fno-tree-forwprop --disable-tree-evrp" } */ > > > +typedef __int128 __attribute__((__vector_size__ (16))) V; > > > + > > > +V > > > +foo (V v) > > > +{ > > > + return (v & (V){15}) == v; > > > +} > > > > > > > > > > > > > > > > > > > -- > > Richard Biener <rguenther@suse.de> > > SUSE Software Solutions Germany GmbH, Frankenstra >
> -----Original Message----- > From: Richard Biener <rguenther@suse.de> > Sent: Thursday, July 7, 2022 8:47 AM > To: Tamar Christina <Tamar.Christina@arm.com> > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com> > Subject: RE: [PATCH]middle-end: don't lower past veclower [PR106063] > > On Thu, 7 Jul 2022, Tamar Christina wrote: > > > > -----Original Message----- > > > From: Richard Biener <rguenther@suse.de> > > > Sent: Thursday, July 7, 2022 8:19 AM > > > To: Tamar Christina <Tamar.Christina@arm.com> > > > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com> > > > Subject: Re: [PATCH]middle-end: don't lower past veclower [PR106063] > > > > > > On Tue, 5 Jul 2022, Tamar Christina wrote: > > > > > > > Hi All, > > > > > > > > My previous patch can cause a problem if the pattern matches after > > > > veclower as it may replace the construct with a vector sequence > > > > which the target may not directly support. > > > > > > > > As such don't perform the rewriting if after veclower. > > > > > > Note that when doing the rewriting before veclower to a variant not > > > supported by the target can cause veclower to generate absymal code. > > > In some cases we are very careful and try to at least preserve code > > > supported by the target over transforming that into a variant not > supported. > > > > > > That said, a better fix would be to check whether the target can > > > perform the new comparison. Before veclower it would be OK to do > > > the transform nevertheless in case it cannot do the original transform. > > > > This last statement is somewhat confusing. Did you want me to change > > it such that before veclower the rewrite is always done and after > > veclowering only if the target supports it? > > > > Or did you want me to never do the rewrite if the target doesn't support it? > > I meant before veclower you can do the rewrite if either the rewriting result > is supported by the target OR if the original expression is _not_ supported by > the target. The latter case might be not too important to worry doing (it > would still canonicalize for those targets then). After veclower you can only > rewrite under the former condition. > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and no issues. Ok for master? and backport to GCC 12? Thanks, Tamar gcc/ChangeLog: PR tree-optimization/106063 * match.pd: Only rewrite if target support it. gcc/testsuite/ChangeLog: PR tree-optimization/106063 * gcc.dg/pr106063.c: New test. --- inline copy of patch --- diff --git a/gcc/match.pd b/gcc/match.pd index 40c09bedadb89dabb6622559a8f69df5384e61fd..5800a105c3cdada9d5e1d8019176ebbe5969ccb0 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -6041,10 +6041,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (cmp (bit_and:c@2 @0 cst@1) integer_zerop) (with { tree csts = bitmask_inv_cst_vector_p (@1); } (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2))) - (if (TYPE_UNSIGNED (TREE_TYPE (@1))) - (icmp @0 { csts; }) - (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); } - (icmp (view_convert:utype @0) { csts; })))))))) + (with { auto optab = VECTOR_TYPE_P (TREE_TYPE (@1)) + ? optab_vector : optab_default; + tree utype = unsigned_type_for (TREE_TYPE (@1)); } + (if (target_supports_op_p (utype, icmp, optab) + || (optimize_vectors_before_lowering_p () + && (!target_supports_op_p (type, cmp, optab) + || !target_supports_op_p (type, BIT_AND_EXPR, optab)))) + (if (TYPE_UNSIGNED (TREE_TYPE (@1))) + (icmp @0 { csts; }) + (icmp (view_convert:utype @0) { csts; }))))))))) /* When one argument is a constant, overflow detection can be simplified. Currently restricted to single use so as not to interfere too much with diff --git a/gcc/testsuite/gcc.dg/pr106063.c b/gcc/testsuite/gcc.dg/pr106063.c new file mode 100644 index 0000000000000000000000000000000000000000..b23596724f6bb98c53af2dce77d31509bab10378 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr106063.c @@ -0,0 +1,9 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fno-tree-forwprop --disable-tree-evrp" } */ +typedef __int128 __attribute__((__vector_size__ (16))) V; + +V +foo (V v) +{ + return (v & (V){15}) == v; +}
On Fri, 8 Jul 2022, Tamar Christina wrote: > > -----Original Message----- > > From: Richard Biener <rguenther@suse.de> > > Sent: Thursday, July 7, 2022 8:47 AM > > To: Tamar Christina <Tamar.Christina@arm.com> > > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com> > > Subject: RE: [PATCH]middle-end: don't lower past veclower [PR106063] > > > > On Thu, 7 Jul 2022, Tamar Christina wrote: > > > > > > -----Original Message----- > > > > From: Richard Biener <rguenther@suse.de> > > > > Sent: Thursday, July 7, 2022 8:19 AM > > > > To: Tamar Christina <Tamar.Christina@arm.com> > > > > Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com> > > > > Subject: Re: [PATCH]middle-end: don't lower past veclower [PR106063] > > > > > > > > On Tue, 5 Jul 2022, Tamar Christina wrote: > > > > > > > > > Hi All, > > > > > > > > > > My previous patch can cause a problem if the pattern matches after > > > > > veclower as it may replace the construct with a vector sequence > > > > > which the target may not directly support. > > > > > > > > > > As such don't perform the rewriting if after veclower. > > > > > > > > Note that when doing the rewriting before veclower to a variant not > > > > supported by the target can cause veclower to generate absymal code. > > > > In some cases we are very careful and try to at least preserve code > > > > supported by the target over transforming that into a variant not > > supported. > > > > > > > > That said, a better fix would be to check whether the target can > > > > perform the new comparison. Before veclower it would be OK to do > > > > the transform nevertheless in case it cannot do the original transform. > > > > > > This last statement is somewhat confusing. Did you want me to change > > > it such that before veclower the rewrite is always done and after > > > veclowering only if the target supports it? > > > > > > Or did you want me to never do the rewrite if the target doesn't support it? > > > > I meant before veclower you can do the rewrite if either the rewriting result > > is supported by the target OR if the original expression is _not_ supported by > > the target. The latter case might be not too important to worry doing (it > > would still canonicalize for those targets then). After veclower you can only > > rewrite under the former condition. > > > > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu > and no issues. > > Ok for master? and backport to GCC 12? OK for master, backport to GCC 12 after a few days of soaking. Thanks, Richard. > Thanks, > Tamar > > > gcc/ChangeLog: > > PR tree-optimization/106063 > * match.pd: Only rewrite if target support it. > > gcc/testsuite/ChangeLog: > > PR tree-optimization/106063 > * gcc.dg/pr106063.c: New test. > > --- inline copy of patch --- > > diff --git a/gcc/match.pd b/gcc/match.pd > index 40c09bedadb89dabb6622559a8f69df5384e61fd..5800a105c3cdada9d5e1d8019176ebbe5969ccb0 100644 > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -6041,10 +6041,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > (cmp (bit_and:c@2 @0 cst@1) integer_zerop) > (with { tree csts = bitmask_inv_cst_vector_p (@1); } > (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2))) > - (if (TYPE_UNSIGNED (TREE_TYPE (@1))) > - (icmp @0 { csts; }) > - (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); } > - (icmp (view_convert:utype @0) { csts; })))))))) > + (with { auto optab = VECTOR_TYPE_P (TREE_TYPE (@1)) > + ? optab_vector : optab_default; > + tree utype = unsigned_type_for (TREE_TYPE (@1)); } > + (if (target_supports_op_p (utype, icmp, optab) > + || (optimize_vectors_before_lowering_p () > + && (!target_supports_op_p (type, cmp, optab) > + || !target_supports_op_p (type, BIT_AND_EXPR, optab)))) > + (if (TYPE_UNSIGNED (TREE_TYPE (@1))) > + (icmp @0 { csts; }) > + (icmp (view_convert:utype @0) { csts; }))))))))) > > /* When one argument is a constant, overflow detection can be simplified. > Currently restricted to single use so as not to interfere too much with > diff --git a/gcc/testsuite/gcc.dg/pr106063.c b/gcc/testsuite/gcc.dg/pr106063.c > new file mode 100644 > index 0000000000000000000000000000000000000000..b23596724f6bb98c53af2dce77d31509bab10378 > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/pr106063.c > @@ -0,0 +1,9 @@ > +/* { dg-do compile } */ > +/* { dg-options "-O2 -fno-tree-forwprop --disable-tree-evrp" } */ > +typedef __int128 __attribute__((__vector_size__ (16))) V; > + > +V > +foo (V v) > +{ > + return (v & (V){15}) == v; > +} >
--- a/gcc/match.pd +++ b/gcc/match.pd @@ -6040,7 +6040,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (simplify (cmp (bit_and:c@2 @0 cst@1) integer_zerop) (with { tree csts = bitmask_inv_cst_vector_p (@1); } - (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2))) + (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)) + && optimize_vectors_before_lowering_p ()) (if (TYPE_UNSIGNED (TREE_TYPE (@1))) (icmp @0 { csts; }) (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); } diff --git a/gcc/testsuite/gcc.dg/pr106063.c b/gcc/testsuite/gcc.dg/pr106063.c new file mode 100644 index 0000000000000000000000000000000000000000..b23596724f6bb98c53af2dce77d31509bab10378 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr106063.c @@ -0,0 +1,9 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fno-tree-forwprop --disable-tree-evrp" } */ +typedef __int128 __attribute__((__vector_size__ (16))) V; + +V +foo (V v) +{ + return (v & (V){15}) == v; +}