Replace `std.builtin.CallingConvention` with a tagged union, eliminating `@setAlignStack` #21697

mlugg · 2024-10-14T22:04:48Z

Huge thanks to @alexrp for the help with this branch -- I absolutely wouldn't have gotten through this without his help.

This PR implements #21209 by replacing std.builtin.CallingConvention with a tagged union and removing @setAlignStack.

The tags of CallingConvention enumerate all major calling conventions for all targets recognised by std.Target. A key design philosophy here is that a CallingConvention tag specifies a calling convention independently of details like the current target or compiler backend; so, rather than e.g. sysv, we have x86_64_sysv, x86_sysv, etc. There is no longer a single tag for the default C calling convention -- more on this in a bit.

The payload of a CallingConvention is a set of options which allow that calling convention to be customized. The vast majority of calling conventions right now have a CommonOptions payload, which allows overriding the incoming stack alignment of the function; that is, the expected boundary the stack pointer is aligned to when the function is called. A few calling conventions have other options; for instance, the x86_sysv tag uses X86RegparmOptions, which allows specifying register_params: u2, which provides an equivalent to Clang's __attribute__((regparm(x))).

A "raw" callconv annotation now has a quite verbose form; for instance, callconv(.{ .x86_64_sysv = .{} }). In most cases, rather than specifying the tag directly like this, the calling convention should instead be specified using one of a handful of declarations on CallingConvention, which are easily used via decl literals, giving a syntax similar to before:

callconv(.c)
// equivalent to
callconv(std.builtin.CallingConvention.c)
// which dispatches to something like...
callconv(.{ .x86_64_sysv = .{} })
// ...depending on target

Right now, there are declarations for c, winapi, and kernel. In addition, there are deprecated declarations acting as aliases for the old CallingConvention tags (Unspecified, C, Interrupt, etc), allowing this whole change to be effectively backwards-compatible in Zig 0.14.0 (note that these aliases should be removed in the 0.15.0 release cycle). In the future, we may want to add some more declarations for convenience; I chose to start small, since it's better to add these in future than to start with too many and break everyone's code when we delete them!

Follow-up tasks:

RISC-V interrupt support (Unable to use callconv(.Interrupt) for riscv targets #20671)
Interrupt fixes from alexrp@77a7268
Verify callconv mappings in link.Dwarf
Handle arm_aapcs16_vfp correctly everywhere (in particular the LLVM backend?)
See if we can support any more CCs in CBE & translate-c
WASM CCs rename?
Remove default for std.builtin.CallingConvention.RiscvInterruptOptions.mode (Remove default field value for std.builtin.CallingConvention.RiscvInterruptOptions.mode #21805)

xdBronch · 2024-10-14T22:19:42Z

zig/lib/std/zig/render.zig

Lines 188 to 189 in 7b8fc18

    
           if (mem.eql(u8, "Inline", tree.tokenSlice(main_tokens[callconv_expr]))) { 
        
               try ais.writer().writeAll("inline ");

should this be updated now?

lib/std/Target.zig

lib/std/builtin.zig

lib/std/start.zig

src/codegen/c.zig

src/link/Dwarf.zig

src/translate_c.zig

src/codegen/llvm.zig

alexrp · 2024-10-14T23:25:53Z

This looks to be missing something like alexrp@77a7268. But note that this commit is incomplete: It's not lowering the interrupt argument, if any, and it also needs to set signal (instead of interrupt) on avr_signal functions. (Clang also sets noinline on interrupt handlers for some targets... but I don't see the point at all since you're not supposed to be able to call these normally in code anyway.)

lib/std/builtin.zig

src/InternPool.zig

src/Value.zig

lib/std/builtin.zig

src/Sema.zig

lib/std/builtin.zig

…ode` The RISC-V specification uses these terms a little interchangably, but "mode" seems more correct here.

There are several more that we could support here, but I didn't feel like going down the rabbit-hole of figuring them out. In particular, some of the Clang enum fields aren't specific enough for us, so we'll have to switch on the target to figure out how to translate-c them. That can be a future enhancement.

…ments

Using `@FieldType` (ziglang#21702).

See riscv/riscv-isa-manual@b6cade0

These only worked before because our lowering of the `AAPCS` calling convention was incorrect in a way which happened to match the ABI of these functions. The tests aren't actually very helpful -- there are already tests for `divmoddi4` etc -- so rather than using inline asm on the caller side to match the ABI, we just delete these two tests. We were for some reason missing a direct test for `__udivmodsi4`, so one has been added.

The whole motivation behind this proposal in the first place was that the LLVM backend disagrees with the self-hosted backends on what `@setAlignStack` meant, so we can't just translate the old logic to the new system! These backends can introduce support for overriding `incoming_stack_alignment` later on.

Looks like the self-hosted riscv64 backend can't handle `std.meta.eql` involving the new `CallingConvention` right now.

mlugg · 2024-10-23T15:49:06Z

@alexrp the follow-up tasks listed in the PR are all yours now. Are you going to work on them imminently, or should I put up issues to track them?

Rexicon226 · 2024-10-23T16:30:50Z

@mlugg mind opening issues for the riscv items, I would like to handle them.

alexrp · 2024-10-24T14:49:56Z

The follow-up work is near the top of my to-do list, so I'll get to it soon-ish. I'm ok letting @Rexicon226 take the RISC-V specific stuff.