On 2/16/25 10:50, Richard Henderson wrote:
On 2/15/25 12:24, Michael Clark wrote:
Why? varargs generally produces horrible code.
The split between alloc and insert was intentional to avoid this.
it's pretty good code on SysV because it goes via registers except for
perhaps new_pool_l8 which will spill to stack and get copied unless
the inliner can eliminate the copies. maybe windows has bad varargs.
but I like the style better than deeper layers of wrapper functions.
they should fix the compiler so that it produces better code.
varargs will generally prevent inlining.
Indeed, just a quick look at aarch64 tcg_out_movi shows that without
your change, new_pool_label, new_pool_data and new_pool_insert are all
inlined. With your change, new_pool_data is not inlined, all the
argument regs are dumped to the stack, etc.
I don't think this is a good change to make.
fixing varargs codegen in GCC/Clang would be a good change. count based
varargs can be reasoned about statically relatively easily. what is it
like with an explicit inline as opposed to just static? I will inspect
anyhow. as varargs with the argument count moved and long as opposed to
format strings is a reasonable pattern for generics in C given C is so
bad at generics. saves lots of long form delegating functions.
I like the representation but understand if you don't take the patch.
