Message ID | patch-16239-tamar@arm.com |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5044:0:0:0:0:0 with SMTP id h4csp120247wrt; Fri, 23 Sep 2022 02:18:31 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5ueZ3OZiegIVAom5DWWm7gwJ6qZzRda2H2zAIDZk2c5ACiHBvFAoYjgv8h1SQZNgO8fgEs X-Received: by 2002:a17:906:fe0b:b0:730:3646:d177 with SMTP id wy11-20020a170906fe0b00b007303646d177mr5831541ejb.688.1663924711101; Fri, 23 Sep 2022 02:18:31 -0700 (PDT) Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id u11-20020aa7db8b000000b004533484fe1bsi6273180edt.563.2022.09.23.02.18.30 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Sep 2022 02:18:31 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=ciuZ4pOZ; arc=fail (signature failed); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B9FE13858034 for <ouuuleilei@gmail.com>; Fri, 23 Sep 2022 09:18:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B9FE13858034 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663924709; bh=3cZmFh41yFaBR5bjqmteztLiwVN3xxOgDaEphTPfk0w=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=ciuZ4pOZfGvVIyo1dZqhkuMGSFFl0feVT72LZjXEqUN6DZ7H6qEUaFeRlijuCh1Yx 69WxGRl6lyeiwesznJO5j5jkkBXHNv9S3upEH/vU2Qu/9E5ZTrQE+7UlUrbN72TkvU WIXTUF+EA8y+HRLj3j4aFDFTFOOmn1m6zLH7hI8A= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80088.outbound.protection.outlook.com [40.107.8.88]) by sourceware.org (Postfix) with ESMTPS id EAF293858C52 for <gcc-patches@gcc.gnu.org>; Fri, 23 Sep 2022 09:17:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EAF293858C52 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=CLlJxWq1Ctq2RAZa9Vb2CstCESD2ugUv/YjNcF7/ZanqmHkJquN24axJCDJnjgY6iRiRW5h7Fk0bXw2RhWv4G6nGDlByybjpTzparI7llEI4GPyU8a/frFe9tlEpGXbZm+lJW+U/6ZUdW0eRhF8hnS9z81qONx/jhwGWg3GhHqi4zYdA544VbJsrieAfWuVujSDREbIPHj18QQsrhbakzuhjnzE10hJJkX+wwqnHJO+V81pRt78k9M6TzfbET8hz4v2cKo/kfeJ3Vp3wCaqzjqRWtNFRaxoqB5w1dSPi7Prj0hVzVDs3ICTJwRVR526YWZfQCaGgsE53MboVl39r/w== 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=3cZmFh41yFaBR5bjqmteztLiwVN3xxOgDaEphTPfk0w=; b=IL4TkemYbRTTKy5R/iEsZ3F4urMn/27sCjbhQ1qQ0DZb3AxVLPypt9UCqQv3OUFz/G8/NJXCcvuskR5JjRoOiaav4X0cgYxR62paaW3mkD0jtPBS3PP/XAEtI3gMymJeH46uQCxKHYHsU+iuSNeDJ4lBC7Xbt+OToR4n3qhuKgeB5SBXBpnzH1mO/qPBb0tSMn7JW/25Ukx43bB6zRKRKtXj2lCp4ikeF6VgKrdh/XOFm+gaJ3VOzjeTrcVESYEiiUys+Ug/Q2zrigsCZESsVP28UMzlh/0e5I2ngjJB3Pv1s8oWSUNUj/b6xNro1zteoAOwcAMFL+mpQeZgPEIg/g== 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 DB6P191CA0011.EURP191.PROD.OUTLOOK.COM (2603:10a6:6:28::21) by AS8PR08MB5880.eurprd08.prod.outlook.com (2603:10a6:20b:29f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.20; Fri, 23 Sep 2022 09:17:37 +0000 Received: from DBAEUR03FT042.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:28:cafe::b4) by DB6P191CA0011.outlook.office365.com (2603:10a6:6:28::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.20 via Frontend Transport; Fri, 23 Sep 2022 09:17:37 +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 DBAEUR03FT042.mail.protection.outlook.com (100.127.142.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.14 via Frontend Transport; Fri, 23 Sep 2022 09:17:37 +0000 Received: ("Tessian outbound ee41cdb23966:v124"); Fri, 23 Sep 2022 09:17:36 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 24515cb2c7a788a3 X-CR-MTA-TID: 64aa7808 Received: from d46b956e712d.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A9AFF06B-55FF-4F5D-B437-8AA81E18647D.1; Fri, 23 Sep 2022 09:17:30 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d46b956e712d.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 23 Sep 2022 09:17:30 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mxcNA6A8S689Vv+P79cWCi838oAOw+0EZOXlsM4unr7ZVgA34iu1xPb6E/ETbVxBEyS9GhNDNORdQJXEp9V1Xx0RaVZYSzlB4CF2r8mS2z/DzMVa6v2MdWDdBiQ7cyzYo/KqLrqoXBkQWvPdPFQZiUz1Fdy7hN0dfV/JrwBTRu9kECOZNzLC55tn4s3MRM6y4NoBvSqIIrgxMgQgSVGkBAPO0yS0GmQZW4DFHp9GKi0XbloXzBCA98H+MRcWtaECPea5Ecseu4hMwVkJl11g6OzZRV/fY04YYdJyMxP3qW0oO9O3GZS4tZv8ZtqMVQ9EBMSFKTiivhLHKSOiaYBWcg== 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=3cZmFh41yFaBR5bjqmteztLiwVN3xxOgDaEphTPfk0w=; b=NnydnEvkLsLBpqFdIXlFO9DT8e5btQziSCdE8bb18dzxAfV6fp3giYfu5l5OhSXosVKVUxMY4vWdyngtIcbESw6f0nWFIj2zHODaduhtKGEI+rRvS7Muft4N/H40MsGfDxKTJvvg0Z0DM7lwN3dZWW2gbqW65Kpup7VdoadKDq3rFPyIyyMDoP8O0E4BTAE4JzcLgqvgMLNpaKx8vZyDtaEH2zt6/DzVTrD+XLDpJtMh4ssT/9IuI8ca3hGsLDAYX5cRJ693tePLl0f9UihxslD2Lo1Ftdhc9uleRZb6IwzAzXIMhi5qmCGoMbVyrWE4Vb62abtVoaew0dR2C5nWZw== 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 DB9PR08MB6444.eurprd08.prod.outlook.com (2603:10a6:10:23c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.20; Fri, 23 Sep 2022 09:17:28 +0000 Received: from VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::6529:66e5:e7d4:1a40]) by VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::6529:66e5:e7d4:1a40%4]) with mapi id 15.20.5632.021; Fri, 23 Sep 2022 09:17:28 +0000 Date: Fri, 23 Sep 2022 10:17:23 +0100 To: gcc-patches@gcc.gnu.org Subject: [PATCH 2/2]AArch64 Add support for neg on v1df Message-ID: <patch-16239-tamar@arm.com> Content-Type: multipart/mixed; boundary="ZWlPBSBKhog1gCmD" Content-Disposition: inline X-ClientProxiedBy: LO2P265CA0151.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::19) To VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB5325:EE_|DB9PR08MB6444:EE_|DBAEUR03FT042:EE_|AS8PR08MB5880:EE_ X-MS-Office365-Filtering-Correlation-Id: e9179342-845e-4548-3308-08da9d4474db 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: 5L43yJIuJtRM6+Nr1s8v8iASVp/A6tJ/Zn2WmGc4XX1r4zLacU+oVjj2eUFH93v5AyRcVQv5BV42ABoOTcIJLeymPOAdYfpJnrcSS1L86epQCoBPbp+rkoWCmDFo1QlRWU8YFtuWSczRd/duQxSZY3vf/TKRHfRnfoIZZvU3TmSNNSlrl5+HxBB47fKYwiiBlnhxs62Dk/5tGCQAn45wkBlQ5+5oB1L7hLnQSBz1TqvmTP4mkly+O3ZpTJhy7dfv2BwRQDW2Z6VoqIeCgRuuxnzt0zPTs1d1NwRGUTSq2NRlBsTMvJnhAsVLbH1qfFPL/pOwBrupUMMiCxE4WUKKz8GRvDGIJUsigDIatAALLBynwScQgWo2/LTbXZO6eazw9B2BEvMY20/HpqqF6/fq60q29iUq89y2NUUbHpch7lWweMqWpXc3yeE80RrQLeweao2apSO47hVGwZHQnjreI+fRV7NpAlQoStoQ9Sya6i7WBHRQ7m+8TfwC+oT1Vq7eLPG/wcVe2SkFJv5VlpcvWo7FpUR1L16DUziRF2B1h0lXb1bXnbKHyjagzFpDX/qIBkkODchdh202dcZgXz7b960EKmtp/uMp2knKHbzjscdlTBuOvW/Rt3Ws85Eblo8DJaiYxDJoRmU6Kg4aGHBTmnwZjA4oB7EC6a9DZepBhYXdHApyu76JjNAJSHekJKWx2pKS+vwQ+1KE4nM6+DubZcZAjx0zIV1lY/bUfEXkuGgHGk/bysbdUMVqw7nO+1kzzSDrSkPo1D4zdF/VJlodj5QqJvHEs/n0o3OeXs7JfEbWcwD5bF420usL8ov7hauyw+IlL9hAo9YaLRKwbb/zKA== 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)(346002)(376002)(136003)(366004)(396003)(39860400002)(451199015)(44832011)(2906002)(66476007)(41300700001)(5660300002)(4326008)(66556008)(66946007)(8676002)(235185007)(8936002)(84970400001)(6486002)(478600001)(186003)(6916009)(2616005)(6666004)(6506007)(316002)(6512007)(4743002)(33964004)(44144004)(36756003)(26005)(38100700002)(86362001)(4216001)(32563001)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6444 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: DBAEUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ceb45789-177c-4886-d837-08da9d446f4e X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: v4hC0dxtdqEva3BkmfyT5a98/vLgGoeSA4Vx8cpnfnKUP6RtMizqc09gpanXTDSvZIF6mPav/iP6WTVbm4LytUo6tTzqrYKEHPtIKcaAgsgvkhYQHPg1uG1rGImIhrrDDgQGSzMQyvJbeB/CVLpqz3Owwe52JYn+FvmWIfS0yJa37ZHtvIZJRiTXnisE1ABPwNuYrOCdclnH9qbAecczZCgn/1lByfKeWOdzjo2a2JNNPgeD2P+xgN+UDJ28LdUJvOp/DThXgmbPFohDJ926Mon6ZAMXv6t1p0ufzfULX1smflXxpp68/jYgbFdYF5imvHt1+3StE+vdnrJCbko3YJgZz/1+rCnTdP/9qN9MTFHay6d6EBfVWoAfJML+0luLGft6TxYfZiM8aereNxNgNL9JawXp13X18eUlRh95g2ew371eLdxp/y58VxNlPRrRip0hsoz+J9UkTaXPdvhhcWHt6BG0QpIhzGlzLa/YdAcZii7t9/LZ9UT2sGOeFn9k+m1hUQ1e/sTHWu7k0j0Rf1x5M1bWhrYQSL8KD4BK5vGLueO+a6aWO74DdDyv7qBJ9U9R5fKzf0yNPOqnzSVd1YP1ws3iBo9roysHz2y+rO5TujYEDiaLKXCkNNcrAObUhU8qDQiVhfZWHog7nX+gFF97+fi103WOdFuePs8/qOHXQIO6ia4kOZY8qkYC83AF7JC3xqkgl1yAqyyeMAH78lYh8Xz3Q7R+EhjRhaqksD4LHAuKinHo/vQBoe0lD89AZ9N5AMl/2s8rM/7NQ21/ZbIjqzUqxrBJB4KngDzNOkuoU9Brgl8wUIR7ZfabGc0rC7vGgAjJM/WjcwY3GrAOO504hlp0bCxBi+XocXiWOhAQ3MPuHfVhR5WHK/mj9kUu 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)(376002)(346002)(39860400002)(396003)(136003)(451199015)(36840700001)(40470700004)(46966006)(186003)(336012)(47076005)(84970400001)(81166007)(41300700001)(82310400005)(82740400003)(5660300002)(235185007)(44832011)(8936002)(36756003)(40480700001)(6666004)(86362001)(356005)(40460700003)(36860700001)(6506007)(6512007)(2616005)(4743002)(26005)(2906002)(316002)(33964004)(44144004)(6916009)(6486002)(478600001)(70586007)(8676002)(4326008)(70206006)(4216001)(32563001)(2700100001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2022 09:17:37.0049 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e9179342-845e-4548-3308-08da9d4474db 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: DBAEUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB5880 X-Spam-Status: No, score=-12.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, KAM_LOTSOFHASH, KAM_SHORT, 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> Cc: Richard.Earnshaw@arm.com, nd@arm.com, richard.sandiford@arm.com, Marcus.Shawcroft@arm.com Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1744751518109883135?= X-GMAIL-MSGID: =?utf-8?q?1744751518109883135?= |
Series |
[1/2] middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend
|
|
Commit Message
Tamar Christina
Sept. 23, 2022, 9:17 a.m. UTC
Hi All, This adds support for using scalar fneg on the V1DF type. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? Thanks, Tamar gcc/ChangeLog: * config/aarch64/aarch64-simd.md (negv1df2): New. gcc/testsuite/ChangeLog: * gcc.target/aarch64/simd/addsub_2.c: New test. --- inline copy of patch -- diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index f4152160084d6b6f34bd69f0ba6386c1ab50f77e..cf8c094bd4b76981cef2dd5dd7b8e6be0d56101f 100644 -- diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index f4152160084d6b6f34bd69f0ba6386c1ab50f77e..cf8c094bd4b76981cef2dd5dd7b8e6be0d56101f 100644 --- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -2713,6 +2713,14 @@ (define_insn "neg<mode>2" [(set_attr "type" "neon_fp_neg_<stype><q>")] ) +(define_insn "negv1df2" + [(set (match_operand:V1DF 0 "register_operand" "=w") + (neg:V1DF (match_operand:V1DF 1 "register_operand" "w")))] + "TARGET_SIMD" + "fneg\\t%d0, %d1" + [(set_attr "type" "neon_fp_neg_d")] +) + (define_insn "abs<mode>2" [(set (match_operand:VHSDF 0 "register_operand" "=w") (abs:VHSDF (match_operand:VHSDF 1 "register_operand" "w")))] diff --git a/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c new file mode 100644 index 0000000000000000000000000000000000000000..55a7365e897f8af509de953129e0f516974f7ca8 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c @@ -0,0 +1,22 @@ +/* { dg-do compile } */ +/* { dg-options "-Ofast" } */ +/* { dg-final { check-function-bodies "**" "" "" { target { le } } } } */ + +#pragma GCC target "+nosve" + +/* +** f1: +** ... +** fneg d[0-9]+, d[0-9]+ +** fadd v[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s +** ... +*/ +void f1 (float *restrict a, float *restrict b, float *res, int n) +{ + for (int i = 0; i < 2; i+=2) + { + res[i+0] = a[i+0] + b[i+0]; + res[i+1] = a[i+1] - b[i+1]; + } +} +
Comments
Tamar Christina <tamar.christina@arm.com> writes: > Hi All, > > This adds support for using scalar fneg on the V1DF type. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? Why just this one operation though? Couldn't we extend iterators like GPF_F16 to include V1DF, avoiding the need for new patterns? Richard > > Thanks, > Tamar > > gcc/ChangeLog: > > * config/aarch64/aarch64-simd.md (negv1df2): New. > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/simd/addsub_2.c: New test. > > --- inline copy of patch -- > diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md > index f4152160084d6b6f34bd69f0ba6386c1ab50f77e..cf8c094bd4b76981cef2dd5dd7b8e6be0d56101f 100644 > --- a/gcc/config/aarch64/aarch64-simd.md > +++ b/gcc/config/aarch64/aarch64-simd.md > @@ -2713,6 +2713,14 @@ (define_insn "neg<mode>2" > [(set_attr "type" "neon_fp_neg_<stype><q>")] > ) > > +(define_insn "negv1df2" > + [(set (match_operand:V1DF 0 "register_operand" "=w") > + (neg:V1DF (match_operand:V1DF 1 "register_operand" "w")))] > + "TARGET_SIMD" > + "fneg\\t%d0, %d1" > + [(set_attr "type" "neon_fp_neg_d")] > +) > + > (define_insn "abs<mode>2" > [(set (match_operand:VHSDF 0 "register_operand" "=w") > (abs:VHSDF (match_operand:VHSDF 1 "register_operand" "w")))] > diff --git a/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > new file mode 100644 > index 0000000000000000000000000000000000000000..55a7365e897f8af509de953129e0f516974f7ca8 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > @@ -0,0 +1,22 @@ > +/* { dg-do compile } */ > +/* { dg-options "-Ofast" } */ > +/* { dg-final { check-function-bodies "**" "" "" { target { le } } } } */ > + > +#pragma GCC target "+nosve" > + > +/* > +** f1: > +** ... > +** fneg d[0-9]+, d[0-9]+ > +** fadd v[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s > +** ... > +*/ > +void f1 (float *restrict a, float *restrict b, float *res, int n) > +{ > + for (int i = 0; i < 2; i+=2) > + { > + res[i+0] = a[i+0] + b[i+0]; > + res[i+1] = a[i+1] - b[i+1]; > + } > +} > +
> -----Original Message----- > From: Richard Sandiford <richard.sandiford@arm.com> > Sent: Friday, September 23, 2022 5:30 AM > 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: [PATCH 2/2]AArch64 Add support for neg on v1df > > Tamar Christina <tamar.christina@arm.com> writes: > > Hi All, > > > > This adds support for using scalar fneg on the V1DF type. > > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > > > Ok for master? > > Why just this one operation though? Couldn't we extend iterators like > GPF_F16 to include V1DF, avoiding the need for new patterns? > Simply because it's the only one I know how to generate code for. I can change GPF_F16 but I don't know under which circumstances we'd generate a V1DF for the other operations. So if it's ok to do so without full test coverage I'm happy to do so... Tamar. > Richard > > > > > Thanks, > > Tamar > > > > gcc/ChangeLog: > > > > * config/aarch64/aarch64-simd.md (negv1df2): New. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/aarch64/simd/addsub_2.c: New test. > > > > --- inline copy of patch -- > > diff --git a/gcc/config/aarch64/aarch64-simd.md > > b/gcc/config/aarch64/aarch64-simd.md > > index > > > f4152160084d6b6f34bd69f0ba6386c1ab50f77e..cf8c094bd4b76981cef2dd5dd7 > b8 > > e6be0d56101f 100644 > > --- a/gcc/config/aarch64/aarch64-simd.md > > +++ b/gcc/config/aarch64/aarch64-simd.md > > @@ -2713,6 +2713,14 @@ (define_insn "neg<mode>2" > > [(set_attr "type" "neon_fp_neg_<stype><q>")] > > ) > > > > +(define_insn "negv1df2" > > + [(set (match_operand:V1DF 0 "register_operand" "=w") > > + (neg:V1DF (match_operand:V1DF 1 "register_operand" "w")))] > > +"TARGET_SIMD" > > + "fneg\\t%d0, %d1" > > + [(set_attr "type" "neon_fp_neg_d")] > > +) > > + > > (define_insn "abs<mode>2" > > [(set (match_operand:VHSDF 0 "register_operand" "=w") > > (abs:VHSDF (match_operand:VHSDF 1 "register_operand" "w")))] > > diff --git a/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > > b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > > new file mode 100644 > > index > > > 0000000000000000000000000000000000000000..55a7365e897f8af509de953129 > e0 > > f516974f7ca8 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > > @@ -0,0 +1,22 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-Ofast" } */ > > +/* { dg-final { check-function-bodies "**" "" "" { target { le } } } > > +} */ > > + > > +#pragma GCC target "+nosve" > > + > > +/* > > +** f1: > > +** ... > > +** fneg d[0-9]+, d[0-9]+ > > +** fadd v[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s > > +** ... > > +*/ > > +void f1 (float *restrict a, float *restrict b, float *res, int n) { > > + for (int i = 0; i < 2; i+=2) > > + { > > + res[i+0] = a[i+0] + b[i+0]; > > + res[i+1] = a[i+1] - b[i+1]; > > + } > > +} > > +
Tamar Christina <Tamar.Christina@arm.com> writes: >> -----Original Message----- >> From: Richard Sandiford <richard.sandiford@arm.com> >> Sent: Friday, September 23, 2022 5:30 AM >> 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: [PATCH 2/2]AArch64 Add support for neg on v1df >> >> Tamar Christina <tamar.christina@arm.com> writes: >> > Hi All, >> > >> > This adds support for using scalar fneg on the V1DF type. >> > >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >> > >> > Ok for master? >> >> Why just this one operation though? Couldn't we extend iterators like >> GPF_F16 to include V1DF, avoiding the need for new patterns? >> > > Simply because it's the only one I know how to generate code for. > I can change GPF_F16 but I don't know under which circumstances we'd generate > a V1DF for the other operations. We'd do it for things like: __Float64x1_t foo (__Float64x1_t x) { return -x; } if the pattern is available, instead of using subregs. So one way would be to scan the expand rtl dump for subregs. If the point is that there is no observable difference between defining 1-element vector ops and not, except for this one case, then that suggests we should handle this case in target-independent code instead. There's no point forcing every target that has V1DF to define a duplicate of the DF neg pattern. Thanks, Richard > > So if it's ok to do so without full test coverage I'm happy to do so... > > Tamar. > >> Richard >> >> > >> > Thanks, >> > Tamar >> > >> > gcc/ChangeLog: >> > >> > * config/aarch64/aarch64-simd.md (negv1df2): New. >> > >> > gcc/testsuite/ChangeLog: >> > >> > * gcc.target/aarch64/simd/addsub_2.c: New test. >> > >> > --- inline copy of patch -- >> > diff --git a/gcc/config/aarch64/aarch64-simd.md >> > b/gcc/config/aarch64/aarch64-simd.md >> > index >> > >> f4152160084d6b6f34bd69f0ba6386c1ab50f77e..cf8c094bd4b76981cef2dd5dd7 >> b8 >> > e6be0d56101f 100644 >> > --- a/gcc/config/aarch64/aarch64-simd.md >> > +++ b/gcc/config/aarch64/aarch64-simd.md >> > @@ -2713,6 +2713,14 @@ (define_insn "neg<mode>2" >> > [(set_attr "type" "neon_fp_neg_<stype><q>")] >> > ) >> > >> > +(define_insn "negv1df2" >> > + [(set (match_operand:V1DF 0 "register_operand" "=w") >> > + (neg:V1DF (match_operand:V1DF 1 "register_operand" "w")))] >> > +"TARGET_SIMD" >> > + "fneg\\t%d0, %d1" >> > + [(set_attr "type" "neon_fp_neg_d")] >> > +) >> > + >> > (define_insn "abs<mode>2" >> > [(set (match_operand:VHSDF 0 "register_operand" "=w") >> > (abs:VHSDF (match_operand:VHSDF 1 "register_operand" "w")))] >> > diff --git a/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c >> > b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c >> > new file mode 100644 >> > index >> > >> 0000000000000000000000000000000000000000..55a7365e897f8af509de953129 >> e0 >> > f516974f7ca8 >> > --- /dev/null >> > +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c >> > @@ -0,0 +1,22 @@ >> > +/* { dg-do compile } */ >> > +/* { dg-options "-Ofast" } */ >> > +/* { dg-final { check-function-bodies "**" "" "" { target { le } } } >> > +} */ >> > + >> > +#pragma GCC target "+nosve" >> > + >> > +/* >> > +** f1: >> > +** ... >> > +** fneg d[0-9]+, d[0-9]+ >> > +** fadd v[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s >> > +** ... >> > +*/ >> > +void f1 (float *restrict a, float *restrict b, float *res, int n) { >> > + for (int i = 0; i < 2; i+=2) >> > + { >> > + res[i+0] = a[i+0] + b[i+0]; >> > + res[i+1] = a[i+1] - b[i+1]; >> > + } >> > +} >> > +
> -----Original Message----- > From: Richard Sandiford <richard.sandiford@arm.com> > Sent: Friday, September 23, 2022 6:04 AM > 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: [PATCH 2/2]AArch64 Add support for neg on v1df > > Tamar Christina <Tamar.Christina@arm.com> writes: > >> -----Original Message----- > >> From: Richard Sandiford <richard.sandiford@arm.com> > >> Sent: Friday, September 23, 2022 5:30 AM > >> 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: [PATCH 2/2]AArch64 Add support for neg on v1df > >> > >> Tamar Christina <tamar.christina@arm.com> writes: > >> > Hi All, > >> > > >> > This adds support for using scalar fneg on the V1DF type. > >> > > >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > >> > > >> > Ok for master? > >> > >> Why just this one operation though? Couldn't we extend iterators > >> like > >> GPF_F16 to include V1DF, avoiding the need for new patterns? > >> > > > > Simply because it's the only one I know how to generate code for. > > I can change GPF_F16 but I don't know under which circumstances we'd > > generate a V1DF for the other operations. > > We'd do it for things like: > > __Float64x1_t foo (__Float64x1_t x) { return -x; } > > if the pattern is available, instead of using subregs. So one way would be to > scan the expand rtl dump for subregs. Ahh yes, I forgot about that ACLE type. > > If the point is that there is no observable difference between defining 1- > element vector ops and not, except for this one case, then that suggests we > should handle this case in target-independent code instead. There's no point > forcing every target that has V1DF to define a duplicate of the DF neg > pattern. My original approach was to indeed use DF instead of V1DF, however since we do define V1DF I had expected the mode to be somewhat usable. So I'm happy to do whichever one you prefer now that I know how to test it. I can either change my mid-end code, or extend the coverage of V1DF, any preference? 😊 Tamar > > Thanks, > Richard > > > > So if it's ok to do so without full test coverage I'm happy to do so... > > > > Tamar. > > > >> Richard > >> > >> > > >> > Thanks, > >> > Tamar > >> > > >> > gcc/ChangeLog: > >> > > >> > * config/aarch64/aarch64-simd.md (negv1df2): New. > >> > > >> > gcc/testsuite/ChangeLog: > >> > > >> > * gcc.target/aarch64/simd/addsub_2.c: New test. > >> > > >> > --- inline copy of patch -- > >> > diff --git a/gcc/config/aarch64/aarch64-simd.md > >> > b/gcc/config/aarch64/aarch64-simd.md > >> > index > >> > > >> > f4152160084d6b6f34bd69f0ba6386c1ab50f77e..cf8c094bd4b76981cef2dd5dd7 > >> b8 > >> > e6be0d56101f 100644 > >> > --- a/gcc/config/aarch64/aarch64-simd.md > >> > +++ b/gcc/config/aarch64/aarch64-simd.md > >> > @@ -2713,6 +2713,14 @@ (define_insn "neg<mode>2" > >> > [(set_attr "type" "neon_fp_neg_<stype><q>")] > >> > ) > >> > > >> > +(define_insn "negv1df2" > >> > + [(set (match_operand:V1DF 0 "register_operand" "=w") > >> > + (neg:V1DF (match_operand:V1DF 1 "register_operand" "w")))] > >> > +"TARGET_SIMD" > >> > + "fneg\\t%d0, %d1" > >> > + [(set_attr "type" "neon_fp_neg_d")] > >> > +) > >> > + > >> > (define_insn "abs<mode>2" > >> > [(set (match_operand:VHSDF 0 "register_operand" "=w") > >> > (abs:VHSDF (match_operand:VHSDF 1 "register_operand" > >> > "w")))] diff --git > >> > a/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > >> > b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > >> > new file mode 100644 > >> > index > >> > > >> > 0000000000000000000000000000000000000000..55a7365e897f8af509de953129 > >> e0 > >> > f516974f7ca8 > >> > --- /dev/null > >> > +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > >> > @@ -0,0 +1,22 @@ > >> > +/* { dg-do compile } */ > >> > +/* { dg-options "-Ofast" } */ > >> > +/* { dg-final { check-function-bodies "**" "" "" { target { le } } > >> > +} } */ > >> > + > >> > +#pragma GCC target "+nosve" > >> > + > >> > +/* > >> > +** f1: > >> > +** ... > >> > +** fneg d[0-9]+, d[0-9]+ > >> > +** fadd v[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s > >> > +** ... > >> > +*/ > >> > +void f1 (float *restrict a, float *restrict b, float *res, int n) { > >> > + for (int i = 0; i < 2; i+=2) > >> > + { > >> > + res[i+0] = a[i+0] + b[i+0]; > >> > + res[i+1] = a[i+1] - b[i+1]; > >> > + } > >> > +} > >> > +
Tamar Christina <Tamar.Christina@arm.com> writes: >> -----Original Message----- >> From: Richard Sandiford <richard.sandiford@arm.com> >> Sent: Friday, September 23, 2022 6:04 AM >> 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: [PATCH 2/2]AArch64 Add support for neg on v1df >> >> Tamar Christina <Tamar.Christina@arm.com> writes: >> >> -----Original Message----- >> >> From: Richard Sandiford <richard.sandiford@arm.com> >> >> Sent: Friday, September 23, 2022 5:30 AM >> >> 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: [PATCH 2/2]AArch64 Add support for neg on v1df >> >> >> >> Tamar Christina <tamar.christina@arm.com> writes: >> >> > Hi All, >> >> > >> >> > This adds support for using scalar fneg on the V1DF type. >> >> > >> >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >> >> > >> >> > Ok for master? >> >> >> >> Why just this one operation though? Couldn't we extend iterators >> >> like >> >> GPF_F16 to include V1DF, avoiding the need for new patterns? >> >> >> > >> > Simply because it's the only one I know how to generate code for. >> > I can change GPF_F16 but I don't know under which circumstances we'd >> > generate a V1DF for the other operations. >> >> We'd do it for things like: >> >> __Float64x1_t foo (__Float64x1_t x) { return -x; } >> >> if the pattern is available, instead of using subregs. So one way would be to >> scan the expand rtl dump for subregs. > > Ahh yes, I forgot about that ACLE type. > >> >> If the point is that there is no observable difference between defining 1- >> element vector ops and not, except for this one case, then that suggests we >> should handle this case in target-independent code instead. There's no point >> forcing every target that has V1DF to define a duplicate of the DF neg >> pattern. > > My original approach was to indeed use DF instead of V1DF, however since we > do define V1DF I had expected the mode to be somewhat usable. > > So I'm happy to do whichever one you prefer now that I know how to test it. > I can either change my mid-end code, or extend the coverage of V1DF, any preference? 😊 I don't mind really, as long as we're consistent. Maybe Richi has an opinion. If he doesn't mind either, then I guess it makes sense to define the ops as completely as possible (e.g. equivalently to V2SF), although it doesn't need to be all in one go. Thanks, Richard > Tamar > >> >> Thanks, >> Richard >> > >> > So if it's ok to do so without full test coverage I'm happy to do so... >> > >> > Tamar. >> > >> >> Richard >> >> >> >> > >> >> > Thanks, >> >> > Tamar >> >> > >> >> > gcc/ChangeLog: >> >> > >> >> > * config/aarch64/aarch64-simd.md (negv1df2): New. >> >> > >> >> > gcc/testsuite/ChangeLog: >> >> > >> >> > * gcc.target/aarch64/simd/addsub_2.c: New test. >> >> > >> >> > --- inline copy of patch -- >> >> > diff --git a/gcc/config/aarch64/aarch64-simd.md >> >> > b/gcc/config/aarch64/aarch64-simd.md >> >> > index >> >> > >> >> >> f4152160084d6b6f34bd69f0ba6386c1ab50f77e..cf8c094bd4b76981cef2dd5dd7 >> >> b8 >> >> > e6be0d56101f 100644 >> >> > --- a/gcc/config/aarch64/aarch64-simd.md >> >> > +++ b/gcc/config/aarch64/aarch64-simd.md >> >> > @@ -2713,6 +2713,14 @@ (define_insn "neg<mode>2" >> >> > [(set_attr "type" "neon_fp_neg_<stype><q>")] >> >> > ) >> >> > >> >> > +(define_insn "negv1df2" >> >> > + [(set (match_operand:V1DF 0 "register_operand" "=w") >> >> > + (neg:V1DF (match_operand:V1DF 1 "register_operand" "w")))] >> >> > +"TARGET_SIMD" >> >> > + "fneg\\t%d0, %d1" >> >> > + [(set_attr "type" "neon_fp_neg_d")] >> >> > +) >> >> > + >> >> > (define_insn "abs<mode>2" >> >> > [(set (match_operand:VHSDF 0 "register_operand" "=w") >> >> > (abs:VHSDF (match_operand:VHSDF 1 "register_operand" >> >> > "w")))] diff --git >> >> > a/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c >> >> > b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c >> >> > new file mode 100644 >> >> > index >> >> > >> >> >> 0000000000000000000000000000000000000000..55a7365e897f8af509de953129 >> >> e0 >> >> > f516974f7ca8 >> >> > --- /dev/null >> >> > +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c >> >> > @@ -0,0 +1,22 @@ >> >> > +/* { dg-do compile } */ >> >> > +/* { dg-options "-Ofast" } */ >> >> > +/* { dg-final { check-function-bodies "**" "" "" { target { le } } >> >> > +} } */ >> >> > + >> >> > +#pragma GCC target "+nosve" >> >> > + >> >> > +/* >> >> > +** f1: >> >> > +** ... >> >> > +** fneg d[0-9]+, d[0-9]+ >> >> > +** fadd v[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s >> >> > +** ... >> >> > +*/ >> >> > +void f1 (float *restrict a, float *restrict b, float *res, int n) { >> >> > + for (int i = 0; i < 2; i+=2) >> >> > + { >> >> > + res[i+0] = a[i+0] + b[i+0]; >> >> > + res[i+1] = a[i+1] - b[i+1]; >> >> > + } >> >> > +} >> >> > +
On Fri, 23 Sep 2022, Richard Sandiford wrote: > Tamar Christina <Tamar.Christina@arm.com> writes: > >> -----Original Message----- > >> From: Richard Sandiford <richard.sandiford@arm.com> > >> Sent: Friday, September 23, 2022 6:04 AM > >> 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: [PATCH 2/2]AArch64 Add support for neg on v1df > >> > >> Tamar Christina <Tamar.Christina@arm.com> writes: > >> >> -----Original Message----- > >> >> From: Richard Sandiford <richard.sandiford@arm.com> > >> >> Sent: Friday, September 23, 2022 5:30 AM > >> >> 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: [PATCH 2/2]AArch64 Add support for neg on v1df > >> >> > >> >> Tamar Christina <tamar.christina@arm.com> writes: > >> >> > Hi All, > >> >> > > >> >> > This adds support for using scalar fneg on the V1DF type. > >> >> > > >> >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > >> >> > > >> >> > Ok for master? > >> >> > >> >> Why just this one operation though? Couldn't we extend iterators > >> >> like > >> >> GPF_F16 to include V1DF, avoiding the need for new patterns? > >> >> > >> > > >> > Simply because it's the only one I know how to generate code for. > >> > I can change GPF_F16 but I don't know under which circumstances we'd > >> > generate a V1DF for the other operations. > >> > >> We'd do it for things like: > >> > >> __Float64x1_t foo (__Float64x1_t x) { return -x; } > >> > >> if the pattern is available, instead of using subregs. So one way would be to > >> scan the expand rtl dump for subregs. > > > > Ahh yes, I forgot about that ACLE type. > > > >> > >> If the point is that there is no observable difference between defining 1- > >> element vector ops and not, except for this one case, then that suggests we > >> should handle this case in target-independent code instead. There's no point > >> forcing every target that has V1DF to define a duplicate of the DF neg > >> pattern. > > > > My original approach was to indeed use DF instead of V1DF, however since we > > do define V1DF I had expected the mode to be somewhat usable. > > > > So I'm happy to do whichever one you prefer now that I know how to test it. > > I can either change my mid-end code, or extend the coverage of V1DF, any preference? ? > > I don't mind really, as long as we're consistent. Maybe Richi has an opinion. > > If he doesn't mind either, then I guess it makes sense to define the ops > as completely as possible (e.g. equivalently to V2SF), although it doesn't > need to be all in one go. I don't mind either, we'll see if theres a target vector registers not overlapping FP regisers at some point, then it probably matters so it does seem we should support both variants from the middle-end at least. If we have some noop-conversion target hook that tells us this RTL expansion could use a fallback generating subregs for V1mode modes. Richard. > Thanks, > Richard > > > Tamar > > > >> > >> Thanks, > >> Richard > >> > > >> > So if it's ok to do so without full test coverage I'm happy to do so... > >> > > >> > Tamar. > >> > > >> >> Richard > >> >> > >> >> > > >> >> > Thanks, > >> >> > Tamar > >> >> > > >> >> > gcc/ChangeLog: > >> >> > > >> >> > * config/aarch64/aarch64-simd.md (negv1df2): New. > >> >> > > >> >> > gcc/testsuite/ChangeLog: > >> >> > > >> >> > * gcc.target/aarch64/simd/addsub_2.c: New test. > >> >> > > >> >> > --- inline copy of patch -- > >> >> > diff --git a/gcc/config/aarch64/aarch64-simd.md > >> >> > b/gcc/config/aarch64/aarch64-simd.md > >> >> > index > >> >> > > >> >> > >> f4152160084d6b6f34bd69f0ba6386c1ab50f77e..cf8c094bd4b76981cef2dd5dd7 > >> >> b8 > >> >> > e6be0d56101f 100644 > >> >> > --- a/gcc/config/aarch64/aarch64-simd.md > >> >> > +++ b/gcc/config/aarch64/aarch64-simd.md > >> >> > @@ -2713,6 +2713,14 @@ (define_insn "neg<mode>2" > >> >> > [(set_attr "type" "neon_fp_neg_<stype><q>")] > >> >> > ) > >> >> > > >> >> > +(define_insn "negv1df2" > >> >> > + [(set (match_operand:V1DF 0 "register_operand" "=w") > >> >> > + (neg:V1DF (match_operand:V1DF 1 "register_operand" "w")))] > >> >> > +"TARGET_SIMD" > >> >> > + "fneg\\t%d0, %d1" > >> >> > + [(set_attr "type" "neon_fp_neg_d")] > >> >> > +) > >> >> > + > >> >> > (define_insn "abs<mode>2" > >> >> > [(set (match_operand:VHSDF 0 "register_operand" "=w") > >> >> > (abs:VHSDF (match_operand:VHSDF 1 "register_operand" > >> >> > "w")))] diff --git > >> >> > a/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > >> >> > b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > >> >> > new file mode 100644 > >> >> > index > >> >> > > >> >> > >> 0000000000000000000000000000000000000000..55a7365e897f8af509de953129 > >> >> e0 > >> >> > f516974f7ca8 > >> >> > --- /dev/null > >> >> > +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c > >> >> > @@ -0,0 +1,22 @@ > >> >> > +/* { dg-do compile } */ > >> >> > +/* { dg-options "-Ofast" } */ > >> >> > +/* { dg-final { check-function-bodies "**" "" "" { target { le } } > >> >> > +} } */ > >> >> > + > >> >> > +#pragma GCC target "+nosve" > >> >> > + > >> >> > +/* > >> >> > +** f1: > >> >> > +** ... > >> >> > +** fneg d[0-9]+, d[0-9]+ > >> >> > +** fadd v[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s > >> >> > +** ... > >> >> > +*/ > >> >> > +void f1 (float *restrict a, float *restrict b, float *res, int n) { > >> >> > + for (int i = 0; i < 2; i+=2) > >> >> > + { > >> >> > + res[i+0] = a[i+0] + b[i+0]; > >> >> > + res[i+1] = a[i+1] - b[i+1]; > >> >> > + } > >> >> > +} > >> >> > + >
--- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -2713,6 +2713,14 @@ (define_insn "neg<mode>2" [(set_attr "type" "neon_fp_neg_<stype><q>")] ) +(define_insn "negv1df2" + [(set (match_operand:V1DF 0 "register_operand" "=w") + (neg:V1DF (match_operand:V1DF 1 "register_operand" "w")))] + "TARGET_SIMD" + "fneg\\t%d0, %d1" + [(set_attr "type" "neon_fp_neg_d")] +) + (define_insn "abs<mode>2" [(set (match_operand:VHSDF 0 "register_operand" "=w") (abs:VHSDF (match_operand:VHSDF 1 "register_operand" "w")))] diff --git a/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c new file mode 100644 index 0000000000000000000000000000000000000000..55a7365e897f8af509de953129e0f516974f7ca8 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/simd/addsub_2.c @@ -0,0 +1,22 @@ +/* { dg-do compile } */ +/* { dg-options "-Ofast" } */ +/* { dg-final { check-function-bodies "**" "" "" { target { le } } } } */ + +#pragma GCC target "+nosve" + +/* +** f1: +** ... +** fneg d[0-9]+, d[0-9]+ +** fadd v[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s +** ... +*/ +void f1 (float *restrict a, float *restrict b, float *res, int n) +{ + for (int i = 0; i < 2; i+=2) + { + res[i+0] = a[i+0] + b[i+0]; + res[i+1] = a[i+1] - b[i+1]; + } +} +