Always inline trivial calls that always shrink

[osa1]

Currently a "trivial call" is a function that just calls another function.

(func $foo ...
  (call $target ...))

Where the arguments to $target are all flat instructions like local.get, or
consts.

Currently we inline these functions always only when not optimizing for code
size.

When optimizing for code size, these functions can always be inlined when

1. The arguments to $target are all function argument locals.
2. Each local is used once.
3. In the order they appear in $foo's signature.

When these hold, inlining $foo never increases code size as it doesn't cause
introducing more locals (or drops etc.) at the call sites.

$foo above when these hold looks like this:

(func $foo (param $arg1 ...) (param $arg2 ...)
  (call $target (local.get $arg1) (local.get $arg2)))

Update FunctionInfo type and FunctionInfoScanner to annotate functions with
more detailed "trivial call" information that also contains whether inlining
shrinks code size.

If a function shrinks when inlined always inline it even with -Os.

Otherwise inline it as before, i.e. when not optimizing for code size.

[osa1]

This is a little bit verbose. Should we run a simple pass to clean this up? (eliminate blocks and locals)

[kripken]

We have --inlining-optimizing for that, and that is what the normal pass pipeline uses. --inlining without optimizing is mainly useful for debugging and tests.

[osa1]

Thanks. --inlining-optimizing simplifies the wat in this test quite a bit. Should I use it in these tests, or do we prefer testing smaller units of code with just --inlining?

[osa1]

I reworded the old comment block here but it just repeats the single line of code below, so I think we can also just drop this comment.

[osa1]

@kripken It looks like this revealed an existing undefined behavior in this line:

binaryen/src/passes/OptimizeInstructions.cpp

Line 3612 in 8470f1b

maskLeft = (1ULL << leftMaxBits) - 1;

Apparently leftMaxBits can be 64, there are a few code paths in getMaxBits that return 64, e.g.

binaryen/src/ir/bits.h

Lines 267 to 270 in 8470f1b

	case RotLInt64:
	case RotRInt64:
	case SubInt64:
	return 64;

Is this a blocker? It looks like an existing issue that getMaxBits returns 64, which is used in a left shift.