wasm-ld memory usage

[radekdoulik]

I am experiencing increased memory usage in wasm-ld after upgrading emscripten from 2.0.21 to 2.0.23.

It is breaking multiple tests we have mono/wasm. I checked one of these and I see memory usage peaking around 8.8GB with 2.0.21 and 10.9GB with 2.0.23, which is cca 24% increase. Is this a know issue or expected behavior?

I noticed the -O0 was removed from default arguments to enable the new string tail merging. I tried to disable it with -Wl,-O0 to see whether it will affect the memory load. It remained 10.9GB for that particular case.

[sbc100]

Are you using an LTO build, or is just the linker?

The string tail merging is really the only major change to wasm-ld recently so I would certainly suspect that. Are you sure -Wl,-O0 has no effect?

[radekdoulik]

Are you using an LTO build, or is just the linker?

Not sure how to find out. I do the usual emsdk install 2.0.23 and emsdk activate 2.0.23.

The string tail merging is really the only major change to wasm-ld recently so I would certainly suspect that. Are you sure -Wl,-O0 has no effect?

It has effect on the output .wasm size, but not on the memory load of the tool.

[radekdoulik]

I tried to build current llvm (80e0424b2ce9489bec73dbd3b920c4543a25feb1) and it looks like it was fixed meanwhile. Might have been something outside the lld/wasm sources, which changed?

I will also try to use 2.0.24 to see if it still exists in that version.

[sbc100]

By "LTO build" I mean are you input object files in bitcode format or wasm object file format? i.e. do you compile with -flto?

[sbc100]

It confusing because we also have an LTO build of the toolchain itself. I guess that could also effect the performance of the toolchain but one would hope it would be a win (as opposed to LTO inputs which will always be slower than object file inputs).

[radekdoulik]

By "LTO build" I mean are you input object files in bitcode format or wasm object file format? i.e. do you compile with -flto?

I think we don't use -flto, the input files are .bc, so I think the bitcode format.

[sbc100]

If you don't pass -flto then its unlike the inputs are in bitcode format. They probably named inaccurately (for historical reasons since fastcomp compiler used bitcode objects by default) and it might be worth switching to .o to avoid confusion.

[radekdoulik]

I think we generate the .bc with our crosscompiler.

Meanwhile I tried to rebuild wasm-ld from 2.0.23 5852582532b3eb3ea8da51a1e272d8d017bd36c9 locally and it also doesn't reproduce the increased memory usage. So the issue from official 2.0.23 might be still present.

How does emscripten build wasm-ld?

I build the llvm locally like this:

cmake -S llvm -B build23 -G Ninja -DLLVM_TARGETS_TO_BUILD="WebAssembly" -DCMAKE_BUILD_TYPE="Release" -DLLVM_ENABLE_PROJECTS="lld"
cmake --build build23 -DLLVM_TARGETS_TO_BUILD="WebAssembly" -DCMAKE_BUILD_TYPE="Release" -DLLVM_ENABLE_PROJECTS="lld"

[sbc100]

We don't apply any llvm patches. Our build script is here: https://chromium.googlesource.com/emscripten-releases/+/refs/heads/main/src/build.py#770

We have been experimenting with building clang with LTO but I think you would have needed to install 2.0.23-lto in order to get that version.

Ah, I didn't realized you were producing .bc files from separate (non-emcc/non-clang) toolchain. You might want to investigae emitting those those .bc files to object files instead (or using llc to convert them). Otherwise you are implicitly asking wasm-ld to perform LTO. You can disabled the actual LTO by passing -Wl,-lto-O0 to the linker, but you can't avoid the actual link-time compilation which is going to slow down your link. At least for fast debug builds you might want to do seperate compilation to make the link super fast. Then for release builds you can stick with LTO objects (.bc files).

[radekdoulik]

Ah, I didn't realized you were producing .bc files from separate (non-emcc/non-clang) toolchain. You might want to investigae emitting those those .bc files to object files instead (or using llc to convert them)

We have that in the works. Hopefully that will help with the memory usage too.