[llvm-dev] [RFC] Allocatable Global Register Variables for ARM

[Carey Williams via llvm-dev]

Hello,
Just a quick note to say there is now an updated patch for this at https://reviews.llvm.org/D68862

Main changes are:
- It is now mandatory to use the -ffixed-rN if register N is used as a Global Register Variable.
- We throw an error rather than a warning in clang and llvm if the user is trying to set -ffixed-rN for the target's frame pointer.
- We dropped the support for r5 due to some hardcoded usage in ARM backend (segmented stacks).
________________________________
From: Amilendra Kodithuwakku <Amilendra.Kodithuwakku at arm.com>
Sent: 11 January 2019 20:51
To: Friedman, Eli <efriedma at codeaurora.org>; Carey Williams <Carey.Williams at arm.com>
Cc: cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [RFC] Allocatable Global Register Variables for ARM


Hi Eli,

> You're correct that any solution that works with LTO must encode the information into the object file.
> But module metadata isn't the best way to do that here.
> The approach I'm suggesting is to use the "target-features" attribute on each function in the file.
> See https://reviews.llvm.org/D46552 /  https://reviews.llvm.org/D48581 / https://reviews.llvm.org/D46552 / etc.

We took your advice and redid our work to use target-features instead of using module-metadata.
With these patches, declaring the register variable in source will not reserve a register,
and  to reserve the register rN, -ffixed-rN should be specified in the command line.
Reserving a register rN by -ffixed-rN will prevent them from being callee-saved.
While we initially expected to support the full callee-saved register set (R4-R11),
the source code shows that R4 is being hard-coded to be used as a scratch register under various conditions,
so for now we revised the supported range of registers from R5-R11.

As you pointed out previously, extra checks have been implemented so that reserved registers will not be spilled for stack alignment purposes.

Effect on existing behavior
----------------------------
1. -ffixed-r9 and -frwpi
The previous implementation of both -ffixed-r9 and -frwpi reserved the register R9, but did not stop it from being callee-saved.
Specifying either flag new implementation reserves R9 and also stops it from being callee-saved.


Errors for conflicting options
------------------------------
The following combination of flags will raise errors.
1. -ffixed-r7 specified without -fomit-frame-pointer or with -fno-omit-frame-pointer
2. -ffixed-r11 specified without -fomit-frame-pointer or with -fno-omit-frame-pointer
3. -ffixed-r9 specified with -frwpi


Draft Patches
-------------
Clang: https://reviews.llvm.org/D56003
LLVM: https://reviews.llvm.org/D56005


Thank you

Amilendra



________________________________
From: Friedman, Eli <efriedma at codeaurora.org>
Sent: Monday, January 7, 2019 10:31 PM
To: Amilendra Kodithuwakku; Carey Williams
Cc: cfe-dev at lists.llvm.org; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Allocatable Global Register Variables for ARM

On 1/4/2019 1:49 AM, Amilendra Kodithuwakku wrote:

> Why did you decide to use global metadata here?  For AArch64, we use a target feature instead, to implement roughly equivalent functionality (the reserve-x18 feature, to implement -ffixed-x18).
> Making a global register declaration have side-effects never made sense, IMO; on the surface, it's using variable declaration syntax, but in reality it's actually changing the ABI rules for the whole file.
> I would prefer to support -ffixed-r4, and never allow global register declarations to modify the ABI. This subset should be compatible with gcc, as far as I know.
>
> (Compiler flags that affect the ABI are easy to misuse, but clang and gcc have a long tradition of flags which change the ABI, so it's not really worse than what we already do.)
>
>
We were looking for a solution which works with LTO.
While we investigated a possible -ffixed-reg flag, our understanding was that it would only work as long as it sets module metadata in the IR.
Adding a -ffixed-reg option in the LLVM backend, and adding that option to the -cc1 command-line, would not work because that would not get passed through to the backend when LTO is used. So our belief was that one could later implement the -ffixed-reg flag upon the module metadata added by this patch.

Is this the target feature mechanism you explained? https://llvm.org/docs/WritingAnLLVMBackend.html#subtarget-support
I still have not gone through the specifics of that but do you know if it would work with LTO?


You're correct that any solution that works with LTO must encode the information into the object file.  But module metadata isn't the best way to do that here.  The approach I'm suggesting is to use the "target-features" attribute on each function in the file.  See https://reviews.llvm.org/D46552 /  https://reviews.llvm.org/D48581 / https://reviews.llvm.org/D46552 / etc.


-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191011/4f7686a7/attachment.html>