feat: add SKIP_OPTIMIZATIONS option to CMakeLists.txt

[kormanowsky]

Added an option named SKIP_OPTIMIZATIONS to help resolve #7566

[kripken]

I am unsure if it makes sense to land this here in upstream. If this were a common use case I'd feel differently, but I haven't heard of this situation before. And while the actual changes are not a large burden, they do add some complexity.

[kormanowsky]

A possible use case of this is to use Binaryen as a part of your own compiler targeting wasm. Wasm itself is being actively developed now and I think it may be used even for learning purposes (for example, as a part of compilers course). These changes make it more convenient to use code generation only (faster compilation, less unused code).

In other words, I see the following flow, which separates compilation and optimisation.

1. Use binaryen to compile something into wasm.
2. Use wasm-opt / other tools to play with compiled code.

@kripken, what do you think of the use case I mentioned? Does it seem irrelevant? Should I change something in the PR so that the changes look more useful for target user described above (maybe change name of the parameter, more comments, …)?

[kripken]

In other words, I see the following flow, which separates compilation and optimisation.

1. Use binaryen to compile something into wasm.
2. Use wasm-opt / other tools to play with compiled code.

What is the benefit of the separation? If you are are already doing 1, then you can tell binaryen to also optimize. That's just one line in the C API for example, and it is more efficient than doing optimizations separately.

And if you are separating 1 and 2 but using wasm-opt in part 2, then you are still using all of binaryen, so this PR won't help?

I can see a use case where you just don't want step 2, so you aren't optimizing at all. But this PR only helps by reducing the build size of binaryen by a few MB, which I'm not sure is a common issue? (I don't recall other people mentioning it.)

[kormanowsky]

What is the benefit of the separation?

The benefit is that you are able to compile many things into wasm modules (possibly in parallel), then link them together via something like wasm-ld, and finally optimize the entire linked module using wasm-opt.

[kripken]

The benefit is that you are able to compile many things into wasm modules (possibly in parallel), then link them together via something like wasm-ld, and finally optimize the entire linked module using wasm-opt.

If you are using all of wasm-opt at the end, why do you want a trimmed-down version of it as well? (Why not use the same wasm-opt for the early compilation and the late optimization?)

[kormanowsky]

In my opinion, this is better for logically distinguishing 3 different steps of the process and for (possibly) better parallelism. This allows using compiler-backend-only tool during (paralleled?) compilation without the need of loading more code into memory. And then you may use (or not use, if you don’t need it, e. g. for debugging/learning purpose) the optimizer during a separate process possibly on different machine, which only gets the entire compiled&linked file and does just the optimization.

[tlively]

If the compile time is a problem for your use case, can you just use the release binaries instead?

[kormanowsky]

In short, it is not compile time only, the file size/amount of files/compexity also matters.

Let me provide more general use case which is similar to mine.

1. Wasm itself is now under active development so I think more people will look towards it for in their tasks.

2. In particular, these people will need a (possibly simpler) way to generate wasm code from something else, including from a rare language (e. g. custom-made/proprietary one).

3. Binaryen may serve as a good starting point in terms of a tool to compile something into wasm thanks to its C++ API. No need here to:

• call external programs to compile the code, one may just parse their language (see 2.) and compile in single program;
• learn all the instruction codes of wasm, just to create a MVP of the project;
• try to understand why all these files of optimization steps appear during compilation/why Binaryen is so big in terms of file size (in the issue #7566 I noted that I was able to reduce file size by ~60MB which is 2/3 of the whole size of my relatively small fun pet project).
• carry external binaryen with you if you don’t need to use tools like wasm-opt/required to provide single executable file by your customer.

In other words, I think changes like these may make Binaryen better as a tool for learning wasm/compilation into wasm and/or for faster MVPs for projects related to wasm.

Does it seem irrelevant to what is Binaryen meant for?

[kripken]

These are valid use cases, and Binaryen may be relevant there. What I am not sure of is the benefit of saving some binary size in one part of that story. And there are downsides to making two separate Binaryen builds just to save size in one of them, like a person might try using the smaller one to optimize and get confused why things don't work.

I would change my mind if I saw benchmarks that show the speedup is very significant, and there are multiple users that are asking for this. For now, I think this doesn't make sense here in upstream.

[kormanowsky]

a person might try using the smaller one

This is a naming issue, I think. If the build is named with something like no-optimizations in it, I don’t expect most of users to try to optimize with it.

if I saw benchmarks that show the speedup is very significant and there are multiple users that are asking for this

Ok, I see. Will try to provide some benchmarks later. And then let’s wait for someone else to start asking for this. At least, there is a way to do this in my fork.