Change the Literal class's operator== to be bitwise (WebAssembly#1661)

The change means that nan values will be compared bitwise when writing A == B, and so the float rule of a nan is different from itself would not apply.

I think this is a safer default. In particular this PR fixes a fuzz bug in the rse pass, which placed Literals in a hash table, and due to nan != nan, an infinite loop... Also, looks like we really want a bitwise comparison pretty much everywhere anyhow, as can be seen in the diff here. Really the single place we need a floaty comparison is in the intepreter where we implement f32.eq etc., and there the code was already using the proper code path anyhow.

wasm-ctor-eval improvements (WebAssembly#1631)

*    When we eval a ctor, don't just nop the function body that no longer needs to be executed, also remove the export (as we report the ctor being evalled, and the outside will no longer call it).
*    Run the pass to remove unused global things. This can usually remove evalled ctors (unless something else happens to call them, which can't happen normally as LLVM wouldn't use a ctor in another place, but e.g. duplicate function merging might merge a ctor with another function).

Stack IR (WebAssembly#1623)

This adds a new IR, "Stack IR". This represents wasm at a very low level, as a simple stream of instructions, basically the same as wasm's binary format. This is unlike Binaryen IR which is structured and in a tree format.

This gives some small wins on binary sizes, less than 1% in most cases, usually 0.25-0.50% or so. That's not much by itself, but looking forward this prepares us for multi-value, which we really need an IR like this to be able to optimize well. Also, it's possible there is more we can do already - currently there are just a few stack IR optimizations implemented,

    DCE
    local2stack - check if a set_local/get_local pair can be removed, which keeps the set's value on the stack, which if the stars align it can be popped instead of the get.
    Block removal - remove any blocks with no branches, as they are valid in wasm binary format.

Implementation-wise, the IR is defined in wasm-stack.h. A new StackInst is defined, representing a single instruction. Most are simple reflections of Binaryen IR (an add, a load, etc.), and just pointers to them. Control flow constructs are expanded into multiple instructions, like a block turns into a block begin and end, and we may also emit extra unreachables to handle the fact Binaryen IR has unreachable blocks/ifs/loops but wasm does not. Overall, all the Binaryen IR differences with wasm vanish on the way to stack IR.

Where this IR lives: Each Function now has a unique_ptr to stack IR, that is, a function may have stack IR alongside the main IR. If the stack IR is present, we write it out during binary writing; if not, we do the same binaryen IR => wasm binary process as before (this PR should not affect speed there). This design lets us use normal Passes on stack IR, in particular this PR defines 3 passes:

    Generate stack IR
    Optimize stack IR (might be worth splitting out into separate passes eventually)
    Print stack IR for debugging purposes

Having these as normal passes is convenient as then they can run in parallel across functions and all the other conveniences of our current Pass system. However, a downside of keeping the second IR as an option on Functions, and using normal Passes to operate on it, means that we may get out of sync: if you generate stack IR, then modify binaryen IR, then the stack IR may no longer be valid (for example, maybe you removed locals or modified instructions in place etc.). To avoid that, Passes now define if they modify Binaryen IR or not; if they do, we throw away the stack IR.

Miscellaneous notes:

    Just writing Stack IR, then writing to binary - no optimizations - is 20% slower than going directly to binary, which is one reason why we still support direct writing. This does lead to some "fun" C++ template code to make that convenient: there is a single StackWriter class, templated over the "mode", which is either Binaryen2Binary (direct writing), Binaryen2Stack, or Stack2Binary. This avoids a lot of boilerplate as the 3 modes share a lot of code in overlapping ways.
    Stack IR does not support source maps / debug info. We just don't use that IR if debug info is present.
    A tiny text format comment (if emitting non-minified text) indicates stack IR is present, if it is ((; has Stack IR ;)). This may help with debugging, just in case people forget. There is also a pass to print out the stack IR for debug purposes, as mentioned above.
    The sieve binaryen.js test was actually not validating all along - these new opts broke it in a more noticeable manner. Fixed.
    Added extra checks in pass-debug mode, to verify that if stack IR should have been thrown out, it was. This should help avoid any confusion with the IR being invalid.
    Added a comment about the possible future of stack IR as the main IR, depending on optimization results, following some discussion earlier today.

Clarify what function-parallel passes can do, and fix an asm2wasm bug (…

…WebAssembly#1627)

The problem this fixes is that we made precompute look at globals in WebAssembly#1622, while asm2wasm was creating globals while adding functions and optimizing them - which could race. This was caught by threadSanitizer (with low frequency, so we missed it on the initial landing).

The underlying issue is that function-parallel passes should be able to read global state, just not modify it, and not read other functions' contents (which is why the Call node has a name, not a pointer to a function). This PR clarifies that in the docs, and fixes asm2wasm by not handling function bodies in parallel to creating globals.

Some minor LocalGraph improvements (WebAssembly#1625)

*    Remove the Action class - we just need a pointer to a get or set. This simplifies the code and saves a little memory, but doesn't seem to have any impact on speed.
*    Miscellaneous code style and comment changes.

Refactor stack writing code into a new StackWriter class (WebAssembly…

…#1620)

This separates out the WasmBinaryWriter parts that do stack writing into a separate class, StackWriter. Previously the WasmBinaryWriter did both the general writing and the stack stuff, and the stack stuff has global state, which it manually cleaned up etc. - seems nicer to have it as a separate class, a class focused on just that one thing.

Should be no functional changes in this PR.

Also add a timeout to the wasm-reduce test, which happened to fail on one of the commits here. It was running slower on that commit for some reason, could have been random - I verified that general wasm writing speed is unaffected by this PR. (But I added the timeout to prevent future random timeouts.)

Fix out-of-tree install of wasm.js (WebAssembly#1616)

Stop bundling binaryen.js builds (WebAssembly#1609)

Instead, we point users to the bot @dcodeIO has, see WebAssembly#1571

This is useful because otherwise every change to binaryen.js requires bundling a build here, which is more work for contributors (and also grows the git repo over time).

We still keep a bundled build of wasm.js. We use that for testing of the interpreter currently, and emscripten depends on it. Eventually wasm2asm may replace that. In any case, wasm.js builds are required far less frequently than binaryen.js.

Improve source map parsing to handle whitespace (WebAssembly#1598)

Add -g/--debuginfo flag to wasm-emscripten-finalize (WebAssembly#1584)

This brings this tool into parity with the existing s2wasm