JonChesterfield wrote: Majority of review comments applied. Merged 94083 (with apologies to Matt) and rebased.
I claim the top level strategy of "turn ... into va_list then fix up known call sites" is a reasonable strategy for optimising variadic functions. The target specific quirks being abstracted over by the existing va_list interface is pleasing. The target abstraction here is not totally what I want it to be and there are some simplifying assumptions (e.g. the C calling conv check probably needs to be under target-specific, variadic invokes exist in libc++) that won't survive for long. Still, I think this is a worthwhile step forward. It's the machinery needed to render variadic functions zero cost at compile time, and gives back ends with freedom over their ABI the option to totally ignore variadic functions. @bigboze this is the pass I looked for during the IPU bring up - it would have been great to say "a void *, four byte alignment seems fine" and cross "implement varargs" off the backlog in half an hour, instead of hand implementing the thing in sdag. Shipping this would also mean successfully avoiding implementing varargs in sdag and globalisel for amdgpu, and whatever nvptx codegen uses, so there's a definite code reuse theme from the IR strategy. My near immediate future involves trying to work out what the addrspace/struct/memory-error weirdness on amdgpu is but I'm also looking forward to the variadic wrapper functions in my headers on x64 disappearing at O1 time. https://github.com/llvm/llvm-project/pull/93362 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
