Andy Wingosix thoughts on generating c ~~ https://wingolog.org/archives/2026/02/09/six-thoughts-on-generating-c
Alexander Monakov@wingo somewhat confused by the "for ABI and tail calls, perform manual register allocation" section: if you mean normal global variables, that is not thread-safe, and if you mean register global variables (as a GCC extension), that is not reliable either? and what does "manual register allocation" in section's title stand for?
@amonakov my mutator is single-threaded at the moment, fwiw, so i can just do globals
Per Vognsen@wingo @amonakov Of course, if you're okay with passing a struct context pointer you can just use that. A small bonus is that it can be [rsi+disp8] vs [rip+disp32]. Otherwise thread-locals with local-exec is a nice option on x86-64 since you get to use fs/gs:[disp], but it's a disaster on ARM64, at least with Apple's ABI. You could abstract over all these options with macro ifdefs for the same C code, so it can be compile-time configured per target.
@wingo @amonakov I.e. use macros for the "registers" and the common prefix of the signature so it can be conditionally compiled whichever way. On ARM64 you'd default to the variant with explicit context pointer argument since you have so many ISA-level registers to spend and want to avoid TLS at all cost since the ABI is dogwater.
@pervognsen @amonakov yep struct context pointer is the plan once i have time to digest the wasm threads stuff
@wingo and let me second "wrap stuff with intent": if you have
struct A { int id; } *a;
struct B { int id; } *b;
the compiler can disambiguate a->id vs. b->id
Jordan@wingo #UmActually,
static inline does not guarantee the arguments don’t hit memory. inline means “available to inline” rather than “must inline”, even with static. It usually works out as long as you compile with optimizations on! It’s safer than macros in so many other ways! But it’s not a guarantee.
cassie