Fix extra unreachable generation (#2266)

Currently various expressions handle this differently, and now we
consistently follow this rules:

---
For all non-control-flow value-returning instructions, if a type of an
expression is unreachable, we emit an unreachable and don't emit the
instruction itself. If we don't emit an unreachable, instructions that
follow can have validation failure in wasm binary format. For example:
```
[unreachable] (f32.add
[unreachable]   (i32.eqz
[unreachable]     (unreachable)
                )
                ...
              )
```
This is a valid prgram in binaryen IR, because the unreachable type
propagates out of an expression, making both i32.eqz and f32.add
unreachable. But in binary format, this becomes:
```
unreachable
i32.eqz
f32.add       ;; validation failure; it expects f32 but takes an i32!
```
And here f32.add causes validation failure in wasm validation. So in this
case we add an unreachable to prevent following instructions to consume
the current value (here i32.eqz).

In actual tests, I used `global.get` to an f32 global, which does not
return a value, instead of `f32.add`, because `f32.add` itself will not
be emitted if one of argument is unreachable.

---

So the changes are:
- For instructions that don't return a value, removes unreachable
  emitting code if it exists.
- Add the unreachable emitting code for value-returning instructions if
  there isn't one.
- Check for unreachability only once after emitting all children for
  atomic instructions. Currently only atomic instructions check
  unreachability after visiting each children and bail out right after,
  which is valid, but not consistent with others.
- Don't emit an extra unreachable after a return (and return_call). I
  guess it is unnecessary.

0 files changed, 0 insertions, 0 deletions