Running optimizers without bindings

[dzfrias]

wasm-opt-rs, a bindings provider for Rust, doesn't use the C API to facilitate interactions between binaryen and Rust. It uses a C++ bindings generator, instead.

Right now, wasm-opt-rs's output is not the same as binaryen's, when running at any optimization levels. In the process of fixing this behavior, I've tried to produce a minimal version of the wasm-opt.cpp file:

void optimize(std::string& infile, std::string& outfile) {
  // binaryen exports are namespaced under "wasm"
  wasm::Module wasm;
  wasm.features.enable(wasm::FeatureSet::Default);
  wasm.features.disable(wasm::FeatureSet::None);

  wasm::ModuleReader reader;
  reader.setDWARF(false);
  reader.setProfile(wasm::IRProfile::Normal);
  std::string inputSourceMapFilename;
  reader.read(infile, wasm, inputSourceMapFilename);

  auto passRunner = wasm::PassRunner(&wasm, wasm::PassOptions::getWithDefaultOptimizationOptions());
  passRunner.options.shrinkLevel = 2;
  passRunner.options.optimizeLevel = 2;
  passRunner.options.debugInfo = false;
  passRunner.addDefaultOptimizationPasses();
  passRunner.run();

  wasm::ModuleWriter writer;
  writer.setBinary(true);
  writer.setDebugInfo(false);
  writer.write(wasm, outfile);
}

Even with this, the outputs are not the same. The binary does definitely shrink, but not as drastically as it does with wasm-opt. I've noticed that even invoking wasm-opt without any optimization levels will lower the binary size by a sizeable amount. This doesn't seem to be the case with my minimal reproduction.

What part of the API is missing here? After looking through the codebase for quite a while I feel like I could be missing a small part of the API that enables the default behavior of wasm-opt.

[kripken]

I don't see anything obviously missing. Though you might want to experiment with changing the opt level to 3, and the shrink level to 1 or 0 (as 2 or 1 disable much inlining, which can have a large impact).

Otherwise, they way I would debug this is to run that code and the commandline tool with the same intended optimizations and with BINARYEN_PASS_DEBUG=3 in the env, which will write out in the current directory a wasm file for each pass that is run. Using that output you can verify that the same passes were executed, and also see the changes in each one. The first file logged out (something like byn-{PROCESS_ID}-000-before.wasm) will be identical to the input, and the last one (byn-{PROCESS_ID}-{LARGE_NUMBER}-..) will be the final output file.

[dzfrias]

Taking a look at the sections, the files are the exact same until the custom ones. There's one section that is much, much larger in the wasm-opt-rs version, and all the rest are the same. After stripping those sections, the files are identical. I'm still not quite sure why this is happening, but at least the problem's location is identified. Does wasm-opt do anything with custom sections that wasm-opt-rs wouldn't do?

On a slight side note, is it completely fine to strip custom sections in most production use-cases? As far as I know, WASM runtimes just ignore them. So unless a programmer is intending to use debug info from them, is it safe to assume that they can be stripped?

Also, in case you want it, here's the input file I'm using:

input.wasm.zip

[dzfrias]

Currently, I'm trying to look at the bloated custom section in question. It's related to DWARF debug info. wasm2wat doesn't generate info about custom sections, I believe, so I'm not sure how to look into this part.

[dzfrias]

I was able to dump the DWARF-related custom sections. The dumped .debug_line section of the wasm-opt-rs version has two times the number of lines compared to the wasm-opt version. I found a PR relating to modifying DWARF-related custom sections. As far as I know, this works independently of the passes(?), which might explain the sudden 410kb to 365kb jump.

After diffing the dumps, I found all the DWARF line tables are completely empty in the .debug_line section in the wasm-opt version. They only display the line table metadata, and don't have any actual mappings. Is this the intended behavior?

Aside from the empty line tables, I took a look at wasm-debug.cpp and didn't get any indication as to why the behavior changes in wasm-opt-rs. There's a big #ifdef BUILD_LLVM_DWARF surrounding most of the code, but switching this option off by default in the CMakeLists.txt file didn't change much.

edit:
I went back and tried to not build with -DBUILD_LLVM_DWARF again, and it turns out I didn't actually turn it off in CMakeLists.txt the first time around. After doing that, the binary sizes of wasm-opt and wasm-opt-rs finally matched. I believe this is a bug in wasm-opt-rs, as full conformity was one of the original intents of the project. Although the root original issue presented in this discussion has been found, I'm still curious about the empty DWARF line tables produced by wasm-opt. Again, I'm not sure if this is intended or not.

Regardless, thank you for the continuous help and guidance in this discussion!

[kripken]

Ah, if it is a DWARF section that CMake does in fact affect that. That's not an optimization issue but a matter of debug support. Makes sense now.

About the line tables, Binaryen's DWARF support is somewhat limited so it's possible you're hitting a limitation or bug. In general it should work when few optimizations are run, however.

[dzfrias]

Good to know, thank you. I'll close up this discussion now!