LTO breaks the multi-value (i.e., `experimental-mv`) ABI for WebAssembly in Clang and generates incompatible function signatures

[jonathanmarvens]

I’ve been using the multi-value ABI for WebAssembly in Clang (i.e., -mmultivalue -Xclang -target-abi -Xclang experimental-mv) and it’s been working relatively well. I decided to enable LTO (thin) in the pipeline and everything exploded—the signatures of all of the functions using multi-value returns are changed in the final WebAssembly binary (lowering the multi-value returns to pointer parameters). The linker seems to be the culprit, because all of the signatures in the LLVM bitcode produced for the individual object files are correct (I’ve painstakingly inspected all of them to confirm this). Also, the same problem persists with full LTO.

Given that this is a proprietary project that involves a somewhat complex pipeline, it’s difficult to extract a reasonable sample of the code to reproduce this issue, but I can try to create an example from scratch if necessary.

I think the following Emscripten issues are related to this issue too:

• wasm-ld: warning: function signature mismatch when compiling with -flto=thin emscripten-core/emscripten#10831
• function signature mismatch with thinLTO and iostreams since 3.0.0 emscripten-core/emscripten#15638

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: Jonathan Barronville (jonathanmarvens)

Details

I’ve been using the [multi-value ABI for WebAssembly](https://github.com/WebAssembly/multi-value/blob/61975c83a286b96517659eded062f4e11dbac4c7/proposals/multi-value/Overview.md) in Clang (*i.e.*, `-mmultivalue -Xclang -target-abi -Xclang experimental-mv`) and it’s been working relatively well. I decided to enable LTO (thin) in the pipeline and everything exploded—the signatures of all of the functions using multi-value returns are changed in the final WebAssembly binary (lowering the multi-value returns to pointer parameters). The linker seems to be the culprit, because all of the signatures in the LLVM bitcode produced for the individual object files are correct (I’ve painstakingly inspected all of them to confirm this). Also, the same problem persists with full LTO.

Given that this is a proprietary project that involves a somewhat complex pipeline, it’s difficult to extract a reasonable sample of the code to reproduce this issue, but I can try to create an example from scratch if necessary.

I think the following Emscripten issues are related to this issue too:

• wasm-ld: warning: function signature mismatch when compiling with -flto=thin emscripten-core/emscripten#10831
• function signature mismatch with thinLTO and iostreams since 3.0.0 emscripten-core/emscripten#15638

[dschuff]

I would guess that the linker is not instantiating the WebAssemblyTargetMachine with the MCTargetOptions that tell it to use the multivalue ABI. If you can reproduce your linker command, does it work if you add -mllvm=--target-abi=experimental-mv?

[jonathanmarvens]

@dschuff

If you can reproduce your linker command, does it work if you add -mllvm=--target-abi=experimental-mv?

I was so excited to try that, but sadly, it doesn’t work—same results. Thank you.

[dschuff]

@sbc100 did I get the format of that flag correct? I would have thought that it might work, since --target-abi is one of those flags that just gets added to every program that links the object file, and it seems to work fine for llc without any special other handling.

[dschuff]

(oh @jonathanmarvens maybe also try it with just a single dash, i.e. -mllvm=-target-abi=experimental-mv?)

[sbc100]

The -mllvm=.. is correct yes.

[jonathanmarvens]

@dschuff No, that didn’t work. I think it’d be much better if I could provide an example repository that reflects this issue, so that we don’t have to just throw things at the wall to see what sticks. I want to spend a bit of time to do that. (I wish the project in question was open-source.) Thank you for your help.

[dschuff]

Thanks! I suspect that in the end this will have a straightforward fix, but it will be much easier to get to with a reproducer.

[alexcrichton]

Thomas pointed me over here from my efforts over at WebAssembly/tool-conventions#268, and while it's tough to say without a reproducer my hunch is that this issue would largely "just get fixed" with the ABI scheme being proposed over there. By representing the ABI within LLVM IR I believe it should be possible to more easily ensure that all objects have a consistent view of a function and all agree on what a particular ABI is. There wouldn't need to be any passing of flags and ensuring that all compiler stages get the right set of flags, for example.

In that sense if WebAssembly/tool-conventions#268 lands, and others agree that experimental-mv is ok to phase out as a result, then I'd personally say this could probably be closed once that flag gets removed.