================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
