On 2/15/25 14:40, Michael Clark wrote:
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?
Inline will still be rejected.
r~
