Inlining: Always inline single-use functions

[kripken]

This implements emscripten-core/emscripten#13744

Inlining functions with a single use allows us to remove the function afterward.
That looks highly beneficial, shrinking every single benchmark in emscripten's
benchmark suite, by an average of 2% on the macrobenchmarks and 3.5% on
all of them. Speed also improves, although mostly on the microbenchmarks so
that might be less realistic.

There may be a slight downside to startup time due to emitting larger functions,
but given the baseline compilers in VMs these days it seems worth it, as the
delay would be just to get to the upper tier. On the benchmark suite the risk
seems low.

See more details in the PR above.

[tlively]

🎉 Well that was simple :)

[MaxGraey]

By the way, it's interesting how much this affects to engine's performance, because in this case there is more register's pressure which may lead to suboptimal register allocation in theory. Maybe better do this only for -O3z?

[kripken]

@MaxGraey That is a risk, yes, but I investigated performance in emscripten-core/emscripten#13744 and did not see such downsides.

One possible reason is that VMs are good enough to register allocate well these days. Another is that inlining is an easy case in that all the inlined code ends up in a single big bundle (where the call was). Unless optimizations move it around, it stays there, and it's easy to register-allocate that well - in the worst case, spilling on entering that bundle and leaving it (which is still not worse than the call). No guarantees of course, but it's less risky than other forms of increasing a function's size.

[MaxGraey]

It seems this may affect to performance after recent v8 change:
v8/v8@4722852

[kripken]

Good point @MaxGraey , I'll look into some kind of limit here. We also saw Firefox add a limit recently, so this appears to be a general issue.