Tracking issue: -Zreg-struct-return support in rustc

[ojeda]

i.e. the equivalent of Clang's/GCC's -freg-struct-return. The kernel needs it to support the x86 32-bit architecture, together with -Zregparm=3.

It could potentially be a "global target feature", i.e. a target feature that is required to be set the same way for all compilation units.

• https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-freg-struct-return
• https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-freg-struct-return

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implementation:
  • rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973) #130777
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions & Answers

• Q: Should it affect the Rust ABI? It cannot be documented as doing such, because the Rust ABI is unstable, but should it do so anyways as a quality-of-implementation matter?
  • Currently: We already do this for the Rust ABI implicitly, without needing a compiler flag: Tracking issue: -Zreg-struct-return support in rustc #116973 (comment)
• Q: Should it affect any other ABIs than "C", "cdecl", and "stdcall"?
  • Currently: No.
  • Alternatives: It's not yet clear what ABIs this affects for gcc and clang.
• Q: Should it be accepted on any other architecture than x86_32?
  • Currently: No.
• Q: Does MSVC code use this?

[bjorn3]

For the rust ABI we already do this. For C ABI compat we will need this. I'm not sure it should be a cli argument though as it affects the ABI and thus has to match for all crates. ABI changes are normally specified in the target spec.

[bjorn3]

Looks like there is already a target spec key for this used by eg FreeBSD: abi_return_struct_as_int

[ojeda]

Yeah, it is the target spec vs. CLI discussion. If I recall correctly, at some point the topic was brought up we were told rustc wanted to move away from the JSON target spec file since it was too tied to LLVM. So that leaves built-in targets or CLI flags (or perhaps a new way). Built-in targets cannot be easily configured/experimented with (i.e. users need to revert to the JSON file), we may require different combinations of them depending on the kernel configuration, and diverges from what GCC/Clang offer. CLI flags are more flexible, but the overwhelming majority of users do not need some of these specialized ones.

[Darksonn]

@rustbot label A-rust-for-linux

[azhogin]

Currently: We already do this for the Rust ABI implicitly, without needing a compiler flag
For the rust ABI we already do this

It is not fully correct atm. For structs with 3 fields and more - yes, it works. But 2-field structs are represented by Abi::ScalarPair, not Abi::Aggregate, so { i32; i32 } is not optimized to i64 without the patch.