[fleventynine]

Rigid ABIs aren't necessary for statically linked programs. Ideally, the compiler would look at the usage of the function in context and figure out an ABI specifically for that function that minimizes unnecessary copies and register churn.

IMHO this is the next logical step in LTO; today we leave a lot of code size and performance on the floor in order to meet some arbitrary ABI.

[ozgrakkurt]

Can’t offload everything into the compiler. It is already too slow.

Soon people will demand it just figures out what you are implementing and rewrites your whole codebase

[fleventynine]

> Can’t offload everything into the compiler. It is already too slow.

Speak for yourself. On embedded platforms I'd happily make my compiles twice as slow for 10% code size improvements.

[acedTrex]

> Soon people will demand it just figures out what you are implementing and rewrites your whole codebase

We have this now, it is indeed very slow lol. Gemini is pretty fast however.

[thfuran]

Isn't that what people are using Claude for now?

[layer8]

I would argue that most of today’s performance problems in software are unrelated to ABI.

[stmw]

I would argue that is largely true because we got the ABIs and the hardware to support them to be highly optimized. Thing slow down very quickly if one gets off that hard-won autobahn of ABI efficiency.

[fleventynine]

When looking at the rv32imc emitted by the Rust compiler, it's clear that there would be a lot less code if the compiler could choose different registers than those defined in the ABI for the arguments of leaf functions.

Not to mention issues like the op mentions making it impossible to properly take advantage of RVO with stuff like Result<T> and the default ABI.