alt.hn

3/1/2026 at 5:25:27 PM

The Rust calling convention we deserve (2024)

 https://mcyoung.xyz/2024/04/17/calling-convention/

by cratermoon

3/5/2026 at 4:31:19 AM

I'm writing a HIP (amd gpu kernels) linker in my job and the calling convention is contained in a metadata section in the object file.

Whether the array is passed in registers or pointers can be chosen by the compiler based on factors like profile guided optimization. That the ABI isn't stable doesn't matter because the linker handles it for the programmer.

This is all publicly documented in the llvm docs too so you can write your own loader.

by jjmarr

3/4/2026 at 11:56:23 PM

Can someone explain the part about Diana's $89 dress?

by dataflow

3/5/2026 at 12:52:48 AM

x86_64 function arguments in linux are passed in registers RDI, RSI, RDX, RCX, R8, R9. The mnemonic helps remember the order.

by devinvs

3/4/2026 at 10:18:01 PM

This reads like word games. The article basically argues for optimizing the calling discipline on a per-function basis, using the function body to guide the optimization. That's not a calling convention and definitely not a standard ABI. What they're arguing for is a kind of static optimization mid-way between targeting a calling convention and inlining. That's not a bad idea on its face, but has nothing at all to do with the C ABI. As to whether it would actually improve anything, frankly, I'm half-surprised compilers don't already do this, i.e. for functions where it's deemed too costly to inline, but which aren't externally visible, and the fact that they don't suggests that maybe there's not much to gain here.

I've yet to read an article criticizing the so-called C ABI that doesn't end up effectively changing the problem statement (in this case, into something utterly incomparable), as opposed to providing a better solution to the same problem. Changing the problem statement is often how you arrive at better solutions overall, but don't try to sell it as something it isn't, insinuating that the pre-existing solution is stupid.

by wahern

3/4/2026 at 10:55:49 PM 

  > for functions where it's deemed too costly to inline, but which aren't externally visible
in LTO mode, gcc does

by dmitrygr

3/5/2026 at 1:50:42 AM

> Another reason is compilation time. The more complicated the function signatures, the more prologue/epilogue code we have to generate that LLVM has to chew on. [...]

I know that LLVM completely dominates compilation time, but maybe the improvements from this could make the other bits (i.e. compiling rustc with callconv=fast) fast enough to make up the difference?

by zamalek

3/5/2026 at 3:18:34 AM

I am extremely skeptical that that would be the case. Local stack accesses are pretty guaranteed to be L1 cache hits, and if any memory access can be made fast, it's accesses to the local stack. The general rule of thumb for performance engineering is that you're optimizing for L2 cache misses if you can't fit in L2 cache, so overall, I'd be shocked if this convoluted calling convention could eke out more than a few percent improvement, and even 1% I'm skeptical of. Meanwhile, making 14-argument functions is going to create a lot of extra work in several places for LLVM that I can think of (for starters, most of the SmallVector<Value *, N> handling is choosing 4 or 8 for N, so there's going to be a lot of heap-allocate a 14-element array going on), which will more than eat up the gains you'd be expecting.

by jcranmer

3/4/2026 at 10:03:54 PM

What was the interval of time for Rust having green threads, out of curiosity? How if at all had that affected layout and calling?

by jauntywundrkind

3/4/2026 at 10:16:05 PM

Pre-1.0. Rust removed the green-threads runtime prior to stabilization.

I personally think this was one of the most important changes Rust made; without it, Rust would have been interesting but would not have been able to compete directly with C and C++ for systems programming.

by JoshTriplett

3/4/2026 at 11:09:53 PM

Yep, it would've just been another OCaml with C style syntax.

by satvikpendem

3/4/2026 at 11:17:57 PM

Or another Go, with a mandatory runtime, which would have been a useful language but not something you'd add to a production OS kernel or firmware or similar.

by JoshTriplett

3/4/2026 at 11:22:49 PM

I wonder if we'd have eventually saw something like Nim, which has optional green thread concurrency and a garbage collector. Rust does not have these currently right? At least I haven't heard of them.

by satvikpendem

3/4/2026 at 11:52:35 PM

Some of Rust's async runtimes seem pretty similar to "optional green threads". There's no garbage collection; you can get something like a reference-counted GC by using Arc everywhere, but it's neither automatic nor universal.

Would we have gotten to "optional"? Maybe! But it's hard to predict the counterfactual, especially when substantial success usually has components of both design and luck/right-place-right-time. Rust hit a sweet spot, and it's not clear how a different history of Rust would have turned out.

by JoshTriplett

3/5/2026 at 12:22:59 AM

> without it, Rust would have been interesting

Thanks for articulating what I’ve failed to do for a decade.

by irishcoffee