Monomorphize all the things

[kripken]

Previously call operands were monomorphized (considered as part of the
call context, so we can create a specialized function with those operands
fixed) if they were constant or had a different type than the function
parameter's type. This generalizes that to pull in pretty much all the code
we possibly can, including nested code. For example:

(call $foo
  (struct.new $struct
    (i32.const 10)
    (local.get $x)
    (local.get $y)
  )
)

This can turn into

(call $foo_mono
  (local.get $x)
  (local.get $y)
)

The struct.new and even one of the struct.new's children is moved into the
called function, replacing the original ref argument with two other ones. If the
original called function was this:

(func $foo (param $ref (ref ..))
  ..
)

then the monomorphized function then looks like this:

(func $foo_mono (param $x i32) (param $y i32)
  (local $ref (ref ..))
  (local.set $ref
    (struct.new $struct
      (i32.const 10)
      (local.get $x)
      (local.get $y)
    )
  )
  ..
)

The struct.new and its constant child appear here, and we read the
parameters.

To do this, generalize the code that creates the call context to accept
everything that is impossible to copy (like a local.get) or that would be
tricky and likely unworthwhile (like another call or a tuple). Also check
for effect interactions, as this code motion does some reordering.

For this to work, we need to adjust how we compute the costs we
compare when deciding what to monomorphize. Before we just
compared the called function to the monomorphized called function,
which was good enough when the call context only contained consts,
but now it can contain arbitrarily nested code. The proper comparison
is between these two:

• Old function + call context
• New monomorphized function

Including the call context makes this a fair comparison. In the example
above, the struct.new and the i32.const are part of the call context,
and so they are in the monomorphized function, so if we didn't count
them in other function we'd decide not to optimize anything with a large
context.

The new functionality is tested in a new file. A few parts of existing
tests needed changes to not become pointless after this improvement,
namely by replacing stuff that we now optimize with things that we
don't like replacing an i32.eqz with a local.get. There are also a
handful of test outcomes that change in CAREFUL mode due to the
new cost analysis.

This is the last major work here. After this I think all that is left is
heuristics on what size functions to work etc.

[tlively]

Comments on code so far. Will look at tests next.

[tlively]

Suggested change

	std::unordered_set<Expression*> unMovable;
	std::unordered_set<Expression*> unmovable;

No need to capitalize the M, I think.

[kripken]

Hmm, good point. Looking into this, both unmovable and immovable are words, and apparently immovable fits physical objects better, so I switched to that.

[tlively]

Just as short and slightly clearer.

Suggested change

	auto currUnMovable = unMovable.count(curr) > 0;
	bool currUnMovable = unMovable.count(curr) > 0;

[tlively]

Do we get much benefit from moving partial argument expressions into the function? It seems that leaving some of the leaf expressions as local.gets of arguments will usually inhibit any further optimization of the full argument expression in the callee beyond what could have been done in the caller.

[kripken]

At least sometimes we do. In the example in the top comment, we move the struct.new into the called function, where it might not escape and therefore be optimized out entirely. We don't know that value, but we do still see the big picture better when we move code into the target.

Another example: if a call sends (i32.eqz (local.get $anything)) then we can at least move the i32.eqz, and then the optimizer can see that that has at most 1 bit set.

In general, there is more opportunity to optimize the more we move, I think, but you might be right that opportunities decrease with unknown values as leaves. When I look into tuning I might add a flag to control this (though I hope not to need many flags).

[tlively]

Makes sense, thanks!

[tlively]

But we already scan all its children, so the code would already handle moving entire control flow structures correctly, right?

[kripken]

The problem would be that in general we can move a parent without moving the children. (i32.eqz (local.get $anything)) can be partially optimized, with the eqz moved but not the local.get. But

(block $b
  (br $b)
)

will break if we move the block but not the br. So if we want to move the block we'd need to look ahead (really behind since we traverse in reverse) to see that all the children work out. That might be worth doing but I'm not sure, and it adds complexity.

[tlively]

I see, and trying to partially move an if-else would also cause problems now that I think about it more.

[tlively]

Tests look good!