Tracking Issue for `-Zregparm`

[azhogin]

This is a tracking issue for the -Zregparm flag for x86. It is the equivalent of Clang's/GCC's -mregparm=3. The kernel needs it to support the x86 32-bit architecture, together with -Zreg-struct-return.

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/x86-Function-Attributes.html#index-regparm-function-attribute_002c-x86
• https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mregparm

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: -Zregparm=<N> commandline flag for X86 (#116972) #130432
• 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: No.
  • Alternatives:
    • Maybe yes?
    • Maybe we want to have a modification equivalent to "fastcall" or -Zregparm=3 apply to the Rust ABI implicitly, without -Zregparm affecting it?
• 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? extern "fastcall" does something equivalent to -Zregparm=2, so do MSVC targets even use it, or do they just use fastcall?

[tgross35]

What if we reinvented these options as a way to set the default C ABI, rather than affecting all ABIs? Something like:

-Cdefault-c-abi=cdecl                              # linux32 default
-Cdefault-c-abi=stdcall                            # win32 default
-Cdefault-c-abi=cdecl+regparm(3)                   # regparm only
-Cdefault-c-abi=cdecl+regparm(3)+reg-struct-return # kernel options

There are a couple of things nice about this:

1. It doesn't overwrite other ABIs. If somebody writes extern "cdecl" rather than extern "C", there is probably a reason that would break if that got changed.
2. It makes more sense conceptually: as implemented, the cdecl ABI ceases to be cdecl, but we don't have a name for it.
3. It extends nicely to being able to write extern "cdecl+regparm(3)" fn foo() { /* ... */ }`, if we ever decide this control is useful on a per-function basis.

Regarding the unresolved questions, is there any prior art for regparm being used with stdcall? I'm imagining most Windows-oriented cases that may need something like regparm are just using fastcall or thiscall instead, so I would be a bit hesitant to stabilize stdcall+regparm and effectively invent a stable ABI that isn't used anywhere else.