[clang] [llvm] [clang][WebAssembly] Support reference types in test_function_pointer_signature (PR #150921)

[Derek Schuff via llvm-commits]

================
@@ -246,35 +246,26 @@ Value *CodeGenFunction::EmitWebAssemblyBuiltinExpr(unsigned BuiltinID,
     llvm::FunctionType *LLVMFuncTy =
         cast<llvm::FunctionType>(ConvertType(QualType(FuncTy, 0)));
 
+    bool VarArg = LLVMFuncTy->isVarArg();
     unsigned NParams = LLVMFuncTy->getNumParams();
     std::vector<Value *> Args;
-    Args.reserve(NParams + 3);
+    Args.reserve(NParams + 3 + VarArg);
----------------
dschuff wrote:

Yeah I think varargs is fine here.
But I also just realized that this code doesn't account for the multivalue ABI, where small struct arguments get decomposed into multiple arguments, and also multiple return values. In the tests ([frontend](https://github.com/llvm/llvm-project/blob/main/clang/test/CodeGen/WebAssembly/wasm-arguments.c), [backend](https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/WebAssembly/multivalue.ll)) you can see that for C struct args, the frontend splits them into separate args, so this code should work. The backend also seems to support decomposing LLVM structs, which would not be accounted for here, but I'm not sure that actually matters because this is a C intrinsic. For returns, it looks like we do use struct return in the IR, so with the current code we'd end up with a poison struct value? NOt sure how that would work. maybe for the purposes of this PR, you could try it out with the multivalue ABI and see what happens. If it happens to work (i.e. if we end up correctly lowering the return struct into something reasonable), let's add that test case, and if not, let's just explicitly check for and reject it (or of course you can actually make it work, either in this PR or a followup).

https://github.com/llvm/llvm-project/pull/150921