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

Cranelift: Correctly handle abi calculation for multi-part arguments #9509

Open
bjorn3 opened this issue Oct 24, 2024 · 0 comments
Open

Cranelift: Correctly handle abi calculation for multi-part arguments #9509

bjorn3 opened this issue Oct 24, 2024 · 0 comments

Comments

@bjorn3
Copy link
Contributor

bjorn3 commented Oct 24, 2024

Feature

When lowering a C or Rust type in a clif ir function signature, sometimes it is necessary to split it into multiple clif ir level parameters. For example #[repr(C)] struct F32Array { field0: [f32; 4] } would be split into f32, f32, f32, f32 on arm64. According to the ABI document for pretty much every architecture if at least one of these parts doesn't fit into an argument register anymore, the entire value has to be passed on the stack. Currently there is no way to tell Cranelift to handle this behavior.

Benefit

Required for rust-lang/rustc_codegen_cranelift#1525.

Implementation

@cfallin suggested a couple of options of which the option they preferred is:

put an abstraction in CLIF for "these values are allocated as a unit"; kind of a lightweight aggregate type, only in the signature and only used by the ABI code, so e.g. the group wouldn't otherwise be a first-class value

I also think this is the best option.

Alternatives

The alternatives @cfallin suggested are:

  • make aggregate types part of CLIF, and update Cranelift's ABI code to understand the platform-specific rules for them, like LLVM does
  • "pre-lower" into the needed form one level up. This is pretty ugly and implies knowledge of target platform in CLIF (beyond just datatype sizes as today) but could in principle be hacked together I think...
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

No branches or pull requests

1 participant