Message ID | VI1PR83MB0431809D3F653B39481E740DF8572@VI1PR83MB0431.EURPRD83.prod.outlook.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 3C5B73858419 for <patchwork@sourceware.org>; Wed, 21 Feb 2024 18:31:02 +0000 (GMT) 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-ve1eur01on2091.outbound.protection.outlook.com [40.107.14.91]) by sourceware.org (Postfix) with ESMTPS id C29E73858D1E for <gcc-patches@gcc.gnu.org>; Wed, 21 Feb 2024 18:30:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C29E73858D1E Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=microsoft.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=microsoft.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C29E73858D1E Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.14.91 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1708540236; cv=pass; b=xp9og+H+cd2pY0ykQqdFeYLBjrOm0FhGh1oYVOIRE5nyFdCmQSUZ7Wu2xUWpnMWNzJs0HUKwzlhIxbPZ4pjlgRWGocw+7YCpN8WIZ9u80QHMD/6yYuss0esxYIurtM2vT/9Gszc7C3RcGrsOQq/JbM9+kv6w6qYMv6lrU/AJei8= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1708540236; c=relaxed/simple; bh=J1sqMFJ6NkWLUWcAgLdrKDHDIL2NaioE5LWY8NZuaXk=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=v4rUAKCYtS+DTeMDHK8sN0g1rY6u/hbbO/C9Xe3iP8UsRa/V2y91oFt4z6arahwBRPRUsk45gNVuFgZ+fs3yLmU3UHx6gVJkZVHvg5R5RKRenCPESPAwLzyCOwk2sd6lhSTK46LB0eWUI/V4cQ3gWHnP0N6x+yuSFOacPXxQSeY= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E9y4GKVOGP7r9MZ4YVnKoYj/oFYgXFeCll/3HOPSCiznWNA8rkRRRIM6PiW763QQYYmUxXLK7xFI5IxCSv62OVRMATIt6m5xuBuyA1l672aZpUOnC6d4bXKY2yxAuuwfa6582ewmV7MDt3N9eJjHpBExTz1ZTsLbgtLH06i21kTrUnM4DJTd1U1IGBv28nyDVsG7a9bkTfnt3+uHuGBe6NWFH8Ga8Ma/fiKNZhI0PNuLen7E1Q4ddSLUxkmEctWMewLEMoV8UAW2fUi0JGaZ4FbNe+qVXXdzG0Lt++IMwdimNN/Z64ksv1wWNccRUDQPQpSrof6UC4+XsSAKLqw/sw== 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=sm/MckLn5scTZxBUjVpZAOxlqoqYIlKS0+UfdTQopuw=; b=bgcy89ws0kzJKO1UXctDvs7/kqSpW47huMDnnayULZBRrC9Bvc525dOf/rdwm8D1YOPMyBARQhpsczBA13/Qi4nFbRY0pgh7/Li3Eec8IqSuCsYFMgubKQ4qkjopSnTxtsNcYnXzWtwP15uvFMzGCgtMsQbK+kINsbz1fQxViXsaRMYMP+PwfihZQG4F4CYJMj/KtTKIBDaelUGcH4zjnuKwU8XAS8vPUMEbP5h/74pKMIhNWxDhoAEUfLHdcYONbhVfGu5buo1jwB8ax3D/MVt43HySw97xtx129XqgNEYoTdABY8+gJVES9UnH16tKyJeo8v7Je6xpbgsmlSdCNQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sm/MckLn5scTZxBUjVpZAOxlqoqYIlKS0+UfdTQopuw=; b=T2N6TtrQFTFWfcj8W/jnd4zSK+bZGP/5/x5Jf71WbYZr9GC1ZSNs5t3KuGRVFRQ6S8F2sf4j1S0gQf+PyOdymsg9+QhN6xcJMQzkuHhNMVW+LINyY6eUPhZ7zAKLcgBHRyt4aEypIqAwuB1lG4tY+mXjyUb/42zno1Zz1TUF8YU= Received: from VI1PR83MB0431.EURPRD83.prod.outlook.com (2603:10a6:800:17f::6) by DBAPR83MB0407.EURPRD83.prod.outlook.com (2603:10a6:10:17c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.8; Wed, 21 Feb 2024 18:30:29 +0000 Received: from VI1PR83MB0431.EURPRD83.prod.outlook.com ([fe80::7279:eea0:8540:a0f5]) by VI1PR83MB0431.EURPRD83.prod.outlook.com ([fe80::7279:eea0:8540:a0f5%7]) with mapi id 15.20.7339.007; Wed, 21 Feb 2024 18:30:29 +0000 From: Evgeny Karpov <Evgeny.Karpov@microsoft.com> To: Evgeny Karpov <Evgeny.Karpov@microsoft.com>, "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org> CC: "richard.sandiford@arm.com" <richard.sandiford@arm.com>, "10walls@gmail.com" <10walls@gmail.com>, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>, "mark@harmstone.com" <mark@harmstone.com>, Zac Walker <zacwalker@microsoft.com>, Ron Riddle <Ron.Riddle@microsoft.com>, Radek Barton <radek.barton@microsoft.com> Subject: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI Thread-Topic: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI Thread-Index: AQHaZPQLWVtNSLkAFEiBQ0RhJkcz9A== Date: Wed, 21 Feb 2024 18:30:29 +0000 Message-ID: <VI1PR83MB0431809D3F653B39481E740DF8572@VI1PR83MB0431.EURPRD83.prod.outlook.com> References: <VI1PR83MB04314E947B1CF296708085DDF8572@VI1PR83MB0431.EURPRD83.prod.outlook.com> In-Reply-To: <VI1PR83MB04314E947B1CF296708085DDF8572@VI1PR83MB0431.EURPRD83.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=57576bd1-751e-4189-ac11-c600ca5b612b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2024-02-21T17:14:30Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI1PR83MB0431:EE_|DBAPR83MB0407:EE_ x-ms-office365-filtering-correlation-id: c0cb1a32-7b13-48b9-385b-08dc330b2e4f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iuiy6SbBiy8rWR+tPcwbGijdyMAWHYTs0nP9r5wVrwdKrP35/SLHPcCHPGXGqzT0p/uSJpSwAqf5dE0zE9l7nymgaFmYA6ZtuEWrKwJJzUCLI9b/BZrDynd1U9QAFif0gqmnNU2w1yjtkwRYExrnZIktcaROByAS8r1pFSfbIgA8Ih1mLYJIxpppH60tSIQfNRPupm4wwH+7xTI8g6lhIM1GLWIvW3zrpBmqp7/FeifxSljUJg56zZVvpT+P8Cx8t8jvVemb6g2L6wPb1wkh5sxuwCou6iJTAsZN+k5s8tq4sUJsTXCpPAaeE9bzqiba+ju4ES9y/NvOePRmM//3+WmQFOhT3l1oiWMdvNev1SI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR83MB0431.EURPRD83.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(38070700009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: hBbj61PnficS1zOuJAkISvCREnUitI9KUcnFrMkGhy6F/jlV0gdzryErRuQ9HobYBy0xNhHQbr52E0MTsS6NPF8bCVfqW7CQH7/WOxvayjmCrW5az9ZNujFtrYJXHQmrcc28fMl/oac5uhz5eX66KBQva3oUbCo9UYigqkYmqa/EAxx805qB8JP4m8N/yqzVuKQeLYK0qQbQZwMrClRyq4569xtSkghgCtFMnEqxfcJuBy1E4NUX9okQuPuvBRk1OSTBNCau06+hdMOCDJaht+bqYySTHb7/TUfdSICcQzbr5mVWvjwnfx30WJM43O7uuO3KSPrtx7tqQivEY4t4rUEzKJ34A1FhL4CnT4FEh2qHIr9BCskrWTlAz+KdNqu9WwooYzVBc93DestlaKyMLVS1YlSBKn9O1GzDbG+sTsOTWD5vjvos8URAT8RY9dXpNvUTcUFhQ624rJ3L4tKdO7El4P8quywmNysXGL9elyXNnV3ivO1QQU7zBRMqVUMju6ouLoYBA25zNqrpTsoDRszqJsEnsZeUAaOyQwYjS220yVCnBvAeUzymFwLYVz2TaLlxX73tD1bNFCo09uel8Lmdy/GYvZIWbOdxCTIbJYZolAobaf0c6xSW8Uua6Y0YIvjO+AyddriZvN3+4Z2Nt+QtHuRvZHCTjVle0hRFBaBUSpYVmpqzjoL4Bw0E1O/UVc50YwVUVa6D7vNGp0vBs48com2hJXtQHSNBHZj5+sSxf2w6sLUyDJdvmpKrupzz8nzzJ8RN9hKkl1j9LrjXlhNPZx2xTimcRwe8legRThN+6c8FTM6sbM1k01MdSF39ItGuGSdCb7X7bldxBNMriX9pajf3QYG3vioZmYiywPA16XSnEsxIR+G+ZW0qYZegWQNBiQ7IzmIO9q1wwd2ZKEOwm2GheolixMgsKDlgAnQ/RFz1y+nCDtckGEjy7n7IBrGidU/1BpJqFuhaiATAx9RDQ2yzomOMLjirJjn8ycqhiXNnb5b2cqKS5NYF2rQ1Vdr9y2bmNlrzuBJ3SS15wtHq0cOD6Z6Jzxnr0lyz9q0LXZh8HnO02UYcjVTJbhlmQkL/Mk6Ka6ikTh5wxc8FBqdePkV52LjTs8bQB56iT50ajRL0Gedcc8NVmGNZ5oIynSLNDExZ7ydPMc0fU79kFSvejxk/VBmfqJl5U7eRAYXrc8k6uBWi6056wihvDWSUC8MlCcQy23Q9yjVOyIKa0DkfpFPLDmQNjFlHIQYVqaixBjS0Z6yK1YHS3w1fF8D9mo5o7fcow34by4LMoui6ONaWtW4DFi0GmMv5wqV94wUPJF/v8YM2J90UU0G+1qFImO3zhIicnBqD0V/PZKaaQrvKOPCAzasq6AAgcmm2wyfCS4oKB9LZHwtRSWIzbfdEQ5HSEZFHqaHVS9RsmJnNHkn45kpaSYwz5TN7GiV8Plh4jHpLZANdxzALKadZzG4fnJR41/A+z10EpixmrUlUO6TZLTXE2ihSRt8ToJa5GNZDS8hkjhU7PUox3m+g6o3kryrCTvDe0542hgmV6C5qgm4SDSn8psCnsvCoU7qHz64bKSbIY5WCL9qeuA9PnE5W Content-Type: multipart/mixed; boundary="_002_VI1PR83MB0431809D3F653B39481E740DF8572VI1PR83MB0431EURP_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR83MB0431.EURPRD83.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c0cb1a32-7b13-48b9-385b-08dc330b2e4f X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2024 18:30:29.4096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EzDuE+bscAJr2xN0exSCC2GO3FoxshmxU/ji6nhFhXD/ZkFC40taCbwb6+BYi8pJPvcQiGUfFum5KmBEeR9vFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR83MB0407 X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_SPF_HELO, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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 |
Add aarch64-w64-mingw32 target
|
|
Commit Message
Evgeny Karpov
Feb. 21, 2024, 6:30 p.m. UTC
From 72ca3f49e3eef9b18946b8d4e77019c1441e1a97 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 15:30:33 +0100
Subject: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for
MS ABI
Define the MS ABI for aarch64-w64-mingw32.
Adjust FIXED_REGISTERS and STATIC_CHAIN_REGNUM for different ABIs.
The X18 register is reserved on Windows for the TEB.
gcc/ChangeLog:
* config.gcc: Define TARGET_ARM64_MS_ABI when Arm64 MS ABI is
used.
* config/aarch64/aarch64.h (FIXED_X18): Define if X18
regsiter is fixed.
(CALL_USED_X18): Define if X18 register is call used.
(FIXED_REGISTERS): Adjust FIXED_REGISTERS for different ABIs.
(STATIC_CHAIN_REGNUM): Define STATIC_CHAIN_REGNUM acording to
ABI.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/aarch64.h | 19 ++++++++++++++++---
2 files changed, 17 insertions(+), 3 deletions(-)
Comments
On 21/02/2024 18:30, Evgeny Karpov wrote:
>
+/* X18 reserved for the TEB on Windows. */
+#ifdef TARGET_ARM64_MS_ABI
+# define FIXED_X18 1
+# define CALL_USED_X18 0
+#else
+# define FIXED_X18 0
+# define CALL_USED_X18 1
+#endif
I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs. Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI. Then the mingw port would use that instead of the EABI header.
An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage.
+# define CALL_USED_X18 0
Is that really correct? If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value.
+#ifdef TARGET_ARM64_MS_ABI
+# define STATIC_CHAIN_REGNUM R17_REGNUM
+#else
+# define STATIC_CHAIN_REGNUM R18_REGNUM
+#endif
If we went the enum way, we'd want something like
#define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM)
R.
On 21/02/2024 18:30, Evgeny Karpov wrote:
>
+ tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"
I missed this on first reading...
The GCC port name uses AARCH64, please use that internally rather than other names. The only time when we should be using ARM64 is when it's needed for compatibility with other compilers and that doesn't apply here AFAICT.
R.
Hi Richard,
Thanks for the review!
TARGET_ARM64_MS_ABI refers to the official Microsoft ARM64 ABI naming used for the target.
If AARCH64 is a more preferred name, it will be changed in PATCH v2.
https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170
Regards,
Evgeny
-----Original Message-----
Thursday, February 22, 2024 2:11 PM
Richard Earnshaw (lists) wrote:
On 21/02/2024 18:30, Evgeny Karpov wrote:
>
+ tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"
I missed this on first reading...
The GCC port name uses AARCH64, please use that internally rather than other names. The only time when we should be using ARM64 is when it's needed for compatibility with other compilers and that doesn't apply here AFAICT.
R.
On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote: > > On 21/02/2024 18:30, Evgeny Karpov wrote: > > > +/* X18 reserved for the TEB on Windows. */ > +#ifdef TARGET_ARM64_MS_ABI > +# define FIXED_X18 1 > +# define CALL_USED_X18 0 > +#else > +# define FIXED_X18 0 > +# define CALL_USED_X18 1 > +#endif > > I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs. Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI. Then the mingw port would use that instead of the EABI header. > > An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage. Dynamically might be needed also if we want to support ms_abi attribute and/or -mabi=ms to support the wine folks. Thanks, Andrew Pinski > > +# define CALL_USED_X18 0 > > Is that really correct? If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value. > > +#ifdef TARGET_ARM64_MS_ABI > +# define STATIC_CHAIN_REGNUM R17_REGNUM > +#else > +# define STATIC_CHAIN_REGNUM R18_REGNUM > +#endif > > If we went the enum way, we'd want something like > > #define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM) > > R.
> On 22 Feb 2024, at 17:45, Andrew Pinski <pinskia@gmail.com> wrote: > > On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists) > <Richard.Earnshaw@arm.com> wrote: >> >> On 21/02/2024 18:30, Evgeny Karpov wrote: >>> >> +/* X18 reserved for the TEB on Windows. */ >> +#ifdef TARGET_ARM64_MS_ABI >> +# define FIXED_X18 1 >> +# define CALL_USED_X18 0 >> +#else >> +# define FIXED_X18 0 >> +# define CALL_USED_X18 1 >> +#endif >> >> I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs. Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI. Then the mingw port would use that instead of the EABI header. >> >> An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage. > > Dynamically might be needed also if we want to support ms_abi > attribute and/or -mabi=ms to support the wine folks. X18 is also reserved on Darwin - in my current branch I have it non-dynamic too. Iain > > Thanks, > Andrew Pinski > >> >> +# define CALL_USED_X18 0 >> >> Is that really correct? If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value. >> >> +#ifdef TARGET_ARM64_MS_ABI >> +# define STATIC_CHAIN_REGNUM R17_REGNUM >> +#else >> +# define STATIC_CHAIN_REGNUM R18_REGNUM >> +#endif >> >> If we went the enum way, we'd want something like >> >> #define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM) >> >> R.
On 22.02.2024 18:45, Andrew Pinski wrote: > On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists) > <Richard.Earnshaw@arm.com> wrote: >> On 21/02/2024 18:30, Evgeny Karpov wrote: >> +/* X18 reserved for the TEB on Windows. */ >> +#ifdef TARGET_ARM64_MS_ABI >> +# define FIXED_X18 1 >> +# define CALL_USED_X18 0 >> +#else >> +# define FIXED_X18 0 >> +# define CALL_USED_X18 1 >> +#endif >> >> I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs. Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI. Then the mingw port would use that instead of the EABI header. >> >> An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage. > Dynamically might be needed also if we want to support ms_abi > attribute and/or -mabi=ms to support the wine folks. Wine no longer needs ms_abi, it was needed for PE-in-ELF modules in the past. We use use proper PE files now, so we need a cross compiler, but no special attributes. aarch64-w64-mingw32 is already well supported by Wine when using llvm-mingw, so as soon as GCC properly supports the ABI, Wine should just work with it, in theory. I didn't try it, but I don't see things like vararg support in this patchset nor in the repo, so I assume it won't work yet. Thanks for the work! Jacek
"Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes: > On 21/02/2024 18:30, Evgeny Karpov wrote: >> > +/* X18 reserved for the TEB on Windows. */ > +#ifdef TARGET_ARM64_MS_ABI > +# define FIXED_X18 1 > +# define CALL_USED_X18 0 > +#else > +# define FIXED_X18 0 > +# define CALL_USED_X18 1 > +#endif > > I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs. Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI. Then the mingw port would use that instead of the EABI header. > > An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage. Agreed FWIW. > +# define CALL_USED_X18 0 > > Is that really correct? If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value. I don't think it would do that for fixed registers. For those this is more whether calls are allowed to change the value of x18 or whether x18 is supposed to remain fixed (e.g. set at the start of the thread and not changed thereafter). How does the MS ABI use this register? Same question for Darwin I suppose. Thanks, Richard > > +#ifdef TARGET_ARM64_MS_ABI > +# define STATIC_CHAIN_REGNUM R17_REGNUM > +#else > +# define STATIC_CHAIN_REGNUM R18_REGNUM > +#endif > > If we went the enum way, we'd want something like > > #define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM) > > R.
This change has been refactored based on the review and will be included in v2. Original aarch64.h will remain unchanged, and the required definition for MS ABI will be implemented in aarch64-abi-ms.h. The reference to this file will be added to config.gcc. This change has been verified, and it appears to work correctly. The X18 register should not be used in any case. The call used flag should be set to 0 for the X18 register to prevent its use in function calls. The same applies to the static chain. The X17 register will be used instead of X18. Regards, Evgeny gcc/config.gcc @@ -1263,7 +1263,8 @@ aarch64-*-mingw*) + tm_file="${tm_file} aarch64/aarch64-abi-ms.h" gcc/config/aarch64/aarch64-abi-ms.h /* Copyright */ /* X18 reserved for the TEB on Windows. */ #undef FIXED_REGISTERS #define FIXED_REGISTERS \ { \ 0, 0, 0, 0, 0, 0, 0, 0, /* R0 - R7 */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* R8 - R15 */ \ 0, 0, 1, 0, 0, 0, 0, 0, /* R16 - R23. */ \ 0, 0, 0, 0, 0, 1, 0, 1, /* R24 - R30, SP */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* V0 - V7 */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* V8 - V15 */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* V16 - V23 */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* V24 - V31 */ \ 1, 1, 1, 1, /* SFP, AP, CC, VG */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* P0 - P7 */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* P8 - P15 */ \ 1, 1, /* FFR and FFRT */ \ 1, 1, 1, 1, 1, 1, 1, 1 /* Fake registers */ \ } #undef CALL_REALLY_USED_REGISTERS #define CALL_REALLY_USED_REGISTERS \ { \ 1, 1, 1, 1, 1, 1, 1, 1, /* R0 - R7 */ \ 1, 1, 1, 1, 1, 1, 1, 1, /* R8 - R15 */ \ 1, 1, 0, 0, 0, 0, 0, 0, /* R16 - R23. */ \ 0, 0, 0, 0, 0, 1, 1, 1, /* R24 - R30, SP */ \ 1, 1, 1, 1, 1, 1, 1, 1, /* V0 - V7 */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* V8 - V15 */ \ 1, 1, 1, 1, 1, 1, 1, 1, /* V16 - V23 */ \ 1, 1, 1, 1, 1, 1, 1, 1, /* V24 - V31 */ \ 1, 1, 1, 0, /* SFP, AP, CC, VG */ \ 1, 1, 1, 1, 1, 1, 1, 1, /* P0 - P7 */ \ 1, 1, 1, 1, 1, 1, 1, 1, /* P8 - P15 */ \ 1, 1, /* FFR and FFRT */ \ 0, 0, 0, 0, 0, 0, 0, 0 /* Fake registers */ \ } #undef STATIC_CHAIN_REGNUM #define STATIC_CHAIN_REGNUM R17_REGNUM -----Original Message----- Thursday, February 22, 2024 12:55 PM Richard Earnshaw (lists) wrote: +/* X18 reserved for the TEB on Windows. */ #ifdef TARGET_ARM64_MS_ABI +# define FIXED_X18 1 # define CALL_USED_X18 0 #else # define FIXED_X18 +0 # define CALL_USED_X18 1 #endif I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs. Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI. Then the mingw port would use that instead of the EABI header. An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage. +# define CALL_USED_X18 0 Is that really correct? If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value. +#ifdef TARGET_ARM64_MS_ABI +# define STATIC_CHAIN_REGNUM R17_REGNUM +#else +# define STATIC_CHAIN_REGNUM R18_REGNUM +#endif If we went the enum way, we'd want something like #define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM) R.
Thank you Jacek for clarifying Wine's needs for ms_abi! Work on vararg support is planned. Regards, Evgeny -----Original Message----- Friday, February 23, 2024 5:10 PM Jacek Caban wrote: > Dynamically might be needed also if we want to support ms_abi > attribute and/or -mabi=ms to support the wine folks. Wine no longer needs ms_abi, it was needed for PE-in-ELF modules in the past. We use use proper PE files now, so we need a cross compiler, but no special attributes. aarch64-w64-mingw32 is already well supported by Wine when using llvm-mingw, so as soon as GCC properly supports the ABI, Wine should just work with it, in theory. I didn't try it, but I don't see things like vararg support in this patchset nor in the repo, so I assume it won't work yet. Thanks for the work! Jacek
In user mode on Windows, it points to TEB (Thread Environment Block). more information here https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers https://learn.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-teb Regards, Evgeny -----Original Message----- Friday, February 23, 2024 5:56 PM Richard Sandiford wrote: How does the MS ABI use this register? Same question for Darwin I suppose. Thanks, Richard
diff --git a/gcc/config.gcc b/gcc/config.gcc index 092a091595d..2a9e4c44f50 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -1276,6 +1276,7 @@ aarch64*-*-mingw*) default_use_cxa_atexit=yes need_64bit_isa=yes user_headers_inc_next_post="${user_headers_inc_next_post} float.h" + tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1" ;; aarch64*-wrs-vxworks*) tm_file="${tm_file} elfos.h aarch64/aarch64-elf.h" diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h index 45e901cda64..36916e7a97d 100644 --- a/gcc/config/aarch64/aarch64.h +++ b/gcc/config/aarch64/aarch64.h @@ -536,11 +536,20 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE = AARCH64_FL_SM_OFF; register. GCC internally uses the poly_int variable aarch64_sve_vg instead. */ +/* X18 reserved for the TEB on Windows. */ +#ifdef TARGET_ARM64_MS_ABI +# define FIXED_X18 1 +# define CALL_USED_X18 0 +#else +# define FIXED_X18 0 +# define CALL_USED_X18 1 +#endif + #define FIXED_REGISTERS \ { \ 0, 0, 0, 0, 0, 0, 0, 0, /* R0 - R7 */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* R8 - R15 */ \ - 0, 0, 0, 0, 0, 0, 0, 0, /* R16 - R23 */ \ + 0, 0, FIXED_X18, 0, 0, 0, 0, 0, /* R16 - R23. */ \ 0, 0, 0, 0, 0, 1, 0, 1, /* R24 - R30, SP */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* V0 - V7 */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* V8 - V15 */ \ @@ -564,7 +573,7 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE = AARCH64_FL_SM_OFF; { \ 1, 1, 1, 1, 1, 1, 1, 1, /* R0 - R7 */ \ 1, 1, 1, 1, 1, 1, 1, 1, /* R8 - R15 */ \ - 1, 1, 1, 0, 0, 0, 0, 0, /* R16 - R23 */ \ + 1, 1, CALL_USED_X18, 0, 0, 0, 0, 0, /* R16 - R23. */ \ 0, 0, 0, 0, 0, 1, 1, 1, /* R24 - R30, SP */ \ 1, 1, 1, 1, 1, 1, 1, 1, /* V0 - V7 */ \ 0, 0, 0, 0, 0, 0, 0, 0, /* V8 - V15 */ \ @@ -642,7 +651,11 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE = AARCH64_FL_SM_OFF; uses alloca. */ #define EXIT_IGNORE_STACK (cfun->calls_alloca) -#define STATIC_CHAIN_REGNUM R18_REGNUM +#ifdef TARGET_ARM64_MS_ABI +# define STATIC_CHAIN_REGNUM R17_REGNUM +#else +# define STATIC_CHAIN_REGNUM R18_REGNUM +#endif #define HARD_FRAME_POINTER_REGNUM R29_REGNUM #define FRAME_POINTER_REGNUM SFP_REGNUM #define STACK_POINTER_REGNUM SP_REGNUM