wasm-reduce roundtrip test isn't useful when it comes to custom sections
I have a .wasm file that crashes wasmtime run -g, supposedly because of the included dwarf sections. When trying to run wasm-reduce to get a smaller repro, the roundtrip test always fail and I have to use -f to skip it; it seems reducing can still somehow take place.
If I'm correct, "roundtrip" means parsing to binaryen IR and re-emitting, the output binary module may differ, but the semantics should stay the same. It can be useful when the code/data section is the culprit (as in most cases), but when the custom section comes to play, roundtrip may block the actually useful later passes.
If desired, I can post the original wasm file here; and I'm interested in your opinions, should we do roundtrip only when no custom section is in place? Or print a more informative warning message?
If the "roundtrip" error is shown, that means that
- Running the given command on the wasm produces output A.
- Reading and writing the wasm, and then running the given command on that, produces output B which is different from A.
It is possible that reduction can still work sometimes in such cases, but in general it won't, since every time wasm-reduce makes a small reduction it writes out the module, and it also reads the module after certain operations - specifically running passes and removing functions. Even without those, wasm-reduce will read the module at least once to begin to work on it. That is, the roundtrip test is testing the basic functionality that wasm-reduce needs.
Perhaps we can improve the warning, if it's not clear enough, that would be great of course.