Define soft-float PCS for AArch64 #232
Conversation
There was a problem hiding this comment.
The variant definition looks good to me. I've made some comments/suggestions on the language, some of which could probably do with a second opinion so don't feel that you need to apply them. My intent for most of them is to try and use as similar language as the rest of the document.
aapcs64/aapcs64.rst
Outdated
|
|
||
| * All floating-point types are passed as if they are an integer type with the same bit-width. | ||
|
|
||
| * No types are considered to be HFAs or HVAs, these are treated as if they are non-homogeneous composite types. |
There was a problem hiding this comment.
Does the implementation treat these as just structs of integers (of the appropriate size) for example a struct of two floats would be treated as if it were a struct of two integers.
From the specification
struct S {
int x; // substitute for float
int y; // substitute for float
};
Would be considered a homogenous aggregate, just not a homogenous floating point aggregate. I can't see anything in the argument passing rules that does anything special with this definition so it would behave as if a non-homogenous composite type. However for future changes would we prefer it to be defined as a homogenous aggregate or a non-homogenous composite?
If we do want to go down that route perhaps:
``Types that the base procedure call standard would consider HFAs or HVAs are treated as homogenous aggregates of signed Integral type with the same byte size and alignment."
There was a problem hiding this comment.
I agree that the original wording conflicts with the existing definition of homogenous aggregate, but I think that change could be confusing, since homogenous aggregates of signed Integral type isn't used anywhere else. Maybe it would be better to cut this down to just "No types are considered to be HFAs or HVAs"?
There was a problem hiding this comment.
I'd be happy with just "No types are considered to be HFAs or HVAs" I think that is sufficient for someone to work out what they need to do by following the rest of the rules in the doc and avoids a potentially confusing definition.
aapcs64/aapcs64.rst
Outdated
| Soft-float variant | ||
| ------------------ | ||
|
|
||
| For v8-R CPUs which do not have floating-point instructions or registers, the soft-float variant of the PCS can be used. Arm recommends that this is not used more widely, as most existing AArch64 implementations do have floating-point registers, and this variant is incompatible with the base variant. |
There was a problem hiding this comment.
I think we could use stronger language here. Perhaps
The soft-float variant is defined for Arm v8-R implementations that do not have floating-point instructions or registers. This variant is incompatible with the base procedure call standard and toolchains are not required to support it.
|
One further suggestion, that github won't let me comment on as it isn't part of the patch. Please can you add an entry to the Change history table? |
There was a problem hiding this comment.
Appreciate waiting on me (especially given my holidays causing delays).
I don't really have anything to add -- from what I see we've had good discussion on trying to ensure it is clear the scope across which we expect this variant PCS to act.
I appreciate the work -- thanks both!
With the release of the Cortex-R82, we now have an AArch64 CPU which can be built without any floating-point instructions or registers, so I think we should re-consider our decision to not have a soft-float variant of the AArch64 PCS. I've worded this as a variant over the base PCS, to keep it simple. No compiler implements this yet, but clang does already allow passing floating-point types without an FPU, and seems to implement the first bullet point correctly. I'm working on LLVM patches which will implement bullet points 2 and 3. GCC doesn't currently allow any use of floating-point types without an FPU for AArch64, so we don't need to worry about compatibility with existing code there. For the fourth bullet point, I don't think we need to define the PCS for vector types, because these are only defined by the ACLE when the relevant hardware exists.
ostannard
force-pushed
the
aarch64-soft-float
branch
from
1d2e82c to
d8999b0
Compare
This adds support for the AArch64 soft-float ABI. The specification for this ABI was added by ARM-software/abi-aa#232. Because all existing AArch64 hardware has floating-point hardware, we expect this to be a niche option, only used for embedded systems on R-profile systems. We are going to document that SysV-like systems should only ever use the base (hard-float) PCS variant: ARM-software/abi-aa#233. For that reason, I've not added an option to select the ABI independently of the FPU hardware, instead the new ABI is enabled iff the target architecture does not have an FPU. For testing, I have run this through an ABI fuzzer, but since this is the first implementation it can only test for internal consistency (callers and callees agree on the PCS), not for conformance to the ABI spec.
With the release of the Cortex-R82, we now have an AArch64 CPU which can be built without any floating-point instructions or registers, so I think we should re-consider our decision to not have a soft-float variant of the AArch64 PCS.
I've worded this as a variant over the base PCS, to keep it simple.
No compiler implements this yet, but clang does already allow passing floating-point types without an FPU, and seems to implement the first bullet point correctly. I'm working on LLVM patches which will implement bullet points 2 and 3.
GCC doesn't currently allow any use of floating-point types without an FPU for AArch64, so we don't need to worry about compatibility with existing code there.
For the fourth bullet point, I don't think we need to define the PCS for vector types, because these are only defined by the ACLE when the relevant hardware exists.