This is necessary and sufficient to get simple cases of multiple
return working with multivalue enabled. More complex cases will
require block and loop signatures to be generalized to potentially be
type indices as well.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp | ||
---|---|---|
1269 | report_fatal_error so end users see this too? |
Should there be a limit on how many returns we are willing to return in a multi? or should we have no fallback to sret at all?
llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp | ||
---|---|---|
1269 | By this time we should have legalized everything, so this can be an assert because it should never happen? |
My current thinking is that such a limit should be left up to the ABI logic in the frontend and that in the backend we should turn all aggregate returns by value into multivalue returns with no limit. WDYT?
llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp | ||
---|---|---|
1269 | @sbc100 is right that users should be able to see these errors. These asserts will be triggered when trying to emit nontrivial code with multivalue enabled. |
llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp | ||
---|---|---|
1309 | Why <=2? If multivalues are supported in fastisel later, do we still have that limit? |
I'll land this since it's just a WIP and not ready for users yet. I'm happy to discuss ABI limits and other considerations further and make changes in followups!
llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp | ||
---|---|---|
1309 | Oops, this comment should have been removed. I'm updating this to just bail out of FastISel in the case of multiple return for now. The proper condition to check is Ret->getNumOperands() > 1. |
report_fatal_error so end users see this too?