Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define soft-float PCS for AArch64 #232

Merged
merged 1 commit into from
Feb 7, 2024

Conversation

ostannard
Copy link
Contributor

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.

Copy link
Contributor

@smithp35 smithp35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Show resolved Hide resolved

* 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Show resolved Hide resolved
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@smithp35
Copy link
Contributor

smithp35 commented Dec 5, 2023

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?

Copy link
Contributor

@smithp35 smithp35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've approved the changes. I've added mmalcomson as a reviewer. Will wait to see if he has any further comments before merging.

Copy link
Contributor

@mmalcomson mmalcomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
@smithp35 smithp35 merged commit 5b9c145 into ARM-software:main Feb 7, 2024
1 check passed
ostannard added a commit to llvm/llvm-project that referenced this pull request Feb 15, 2024
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.
Copy link

@sallyarmneale sallyarmneale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor changes required.

aapcs64/aapcs64.rst Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants