Clang compiling to WebAssembly with multivalue and wasm-opt fails

[fluffyball9]

Compiling to WebAssembly using clang with multivalue and wasm-opt on path build fails because clang doesn't automatically pass --enable-multivalue to wasm-opt. This parameter should be automatically passed to wasm-opt.

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

[sbc100]

I think the expect behaviour is that the "target-features" section of the binary should include "multi-value". This should be enough to inform wasm-opt about the features to enable.

[tlively]

@fluffyball9, can you share a clang driver command that reproduces the issue? I wonder if this is caused by the target features section being stripped somehow.

[fluffyball9]

The simplest arguments that reproduces the issue are --target=wasm32 -mmultivalue -Xclang -target-abi -Xclang experimental-mv -nostdlib -O3 -s -Wl,--export-dynamic,--allow-undefined,--gc-sections. Based on what I've tried, it fails with any level of optimization except of O0.

[fluffyball9]

If I run clang with -c and use wasm-dis, the sections at the end of the file are

 ;; custom section "linking", size 579
 ;; custom section "reloc.CODE", size 299
 ;; custom section "producers", size 93
 ;; features section: mutable-globals, sign-ext, multivalue

[tlively]

That features section correctly contains "multivalue". @fluffyball9, what version of wasm-opt do you have in your path? Can you run wasm-opt --help and see if it supports the multivalue feature flag? If it doesn't, then it wouldn't support reading the feature out of the features section, either.

[fluffyball9]

@tlively I'm using wasm-opt version 112. After linking, it seems like the features section is removed.

[tlively]

This seems to work for me.

test.c:

struct pair {
  int a;
  int b;
};

struct pair mv_func(void);

int main() {
  return mv_func().a;
}

Compiling with:
PATH=~/code/binaryen:$PATH clang --verbose --target=wasm32 -mmultivalue -Xclang -target-abi -Xclang experimental-mv -nostdlib -O3 -s -Wl,--export-dynamic,--allow-undefined,--gc-sections,--no-entry test.c -o test.wasm

Finishes with no error, and I verified that it ran wasm-opt.

Can you provide a complete reproducer?

[tlively]

Ah, I noticed that it had optimized main out entirely. If I add --export=main, then I can reproduce the error. investigating further now.

[tlively]

Ok, so the problem is that the -s argument tells the linker to strip all sections, so the target feature section is being stripped. @sbc100, should we make it so that --strip-all does not actually strip the target features section? IIRC, wasm-objdump and wasm-ld are inconsistent here.

[dschuff]

(did you mean wasm-objcopy rather than wasm-objdump?)

[dschuff]

I confirmed that llvm-opjcopy/llvm-strip does not strip the target feature section with --strip-all (see https://github.com/llvm/llvm-project/blob/main/llvm/lib/ObjCopy/wasm/WasmObjcopy.cpp#L76). It only strips sections that it actually understands (linking/reloc, debug, name, producers). Probably makes sense for wasm-ld to do the same?

[sbc100]

To me that would seem to contradict that meaning of --strip-all. I think if you pass --strip-all the linker you are kind of opting out of being able to run any post-link optimizations . If you want to do post-link stuff like wasm-opt, you should probably be relying on that tool to do that final stripping.

I guess that it might be more ergonomic just to never strip the target-features section, but what if I'm a user who actually wants to pass --strip-all and then ship the result of that to production. I think having a target-features section in that case would go against the user intent.

How about this: Clang can detect if its going to run wasm-opt after wasm-ld and in that case inject some kind of flag (perhaps a new --preserve-features) to tell wasm-ld about this.

[dschuff]

Yeah, I guess it's the driver's job to manage the tool pipeline, including any flags that affect post-link opt, so moving the logic to the driver makes sense. I think llvm-objcopy/llvm-strip's -keep-section flag overrides the stripping and remove-section flags (see link above), but I'm not sure if lld has any logic like that.

[llvmbot]

@llvm/issue-subscribers-lld-wasm

Author: None (fluffyball9)

Compiling to WebAssembly using clang with multivalue and wasm-opt on path build fails because clang doesn't automatically pass `--enable-multivalue` to wasm-opt. This parameter should be automatically passed to wasm-opt.

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: None (fluffyball9)

Compiling to WebAssembly using clang with multivalue and wasm-opt on path build fails because clang doesn't automatically pass `--enable-multivalue` to wasm-opt. This parameter should be automatically passed to wasm-opt.