[inlining] increasing accuracy of the code size assessment model

[HerrCai0907]

Old code size measure is simply based on operation count in callee. It will miss the opportunity like

(func (param $ptr i32) (param $value i32)
  local.get  $ptr
  local.get $value
  i32.store
)

which is always happened for variable setter in OO language.

In this PR, we want to introduce inlining specific measurer to ignore this pattern for better inlining result.
The new measurer will ignore all occurrences of local.get that occur in sequence.
The behavior of the new measurer will be consistent with that of the old measurer in:

1. When parameters are not retrieved in sequence, a new local variable will be introduced after inlining. At this point, to prevent an increase in code size,
2. produce operand stack with global.get or xxx.const
3. update the value of local with local.set

In a word, the new measure want to match this pattern: The function body only contain local.get $param_n and trivial consumer operation like xxx.add xxx.store if etc.

[kripken]

Interesting idea. Do you have measurements on some benchmark perhaps? I'm not sure I have a good guess about this without data.

[HerrCai0907]

I use assemblyscript bootstrap as bench
wasm-opt flags: --shrink-level 2 --all-features -Oz

wasm-opt	size (Bytes)
main@2b989ae	791963
after PR	792066 (+103)
after PR but treat store as invalid	791896 (-67)

The store will use at least 3 bytes which is 1 byte larger than call, so inline it will increase 1 byte in WASM size. But it is depends on the frequency... But if we only keep the normal algorithm operation, It is definitely profitable.

[HerrCai0907]

And I think it is worth to inline if we want a balance in both shrink level and optimize level. It will not increase code size much and inlining can reduce the cost of function call and introduce more optimization opportunity later.