Optimizing `call_indirect` performance

[fitzgen]

Ideas from a brainstorming session with some Cranelift folks:

• Typed funcrefs can statically remove null checks and sig checks; but how do we use?
  • In cranelift-wasm, need to feed type info from validator to say “non-null”
• Catch calls to null via signal rather than explicit check
• Inline VMFuncRefs into table, instead of having table be a vec of pointers to VMFuncRefs
• Store defined tables directly in the vmctx, rather than indirectly
  • Only works for max size tables
  • Helps with allocating multiple tables inside pooling allocator
• If min and max are equal then table size is constant, don’t load table size from memory, just use the constant
• If table index is constant and less than minimum, skip bounds check

And, of course, it would be nice to have some (micro) benchmarks to measure all of this.

[jameysharp]

I wanted to estimate the impact any of these changes might have on real-world performance. I don't have very good ways to do that but I do have a few observations from the Sightglass spidermonkey benchmark.

There are 1,903 uses of call_indirect in this benchmark. I don't know if any of them are hot but having that many might be a good sign for the impact of these optimizations.

The function table has both minimum and maximum size set to 3,312 elements.

• Using that constant in table bounds-checks, rather than loading the current table size from memory, should be a quick win. If we can't measure any impact from that change then I would suspect that none of these calls are hot in this benchmark.

• Storing that table directly in the vmctx is feasible since its size is known exactly.

• Is lazy table initialization worth doing for ~3k table entries?

There are 21 distinct types used in those 1,903 calls. We discussed, but didn't seriously consider, some ways to split function tables by type signature. If we wanted to pursue something like that then it's nice to know there aren't very many distinct signatures.

Some additional ideas that I don't think we discussed the other day:

• Do type-checking in the callee rather than the caller. This avoids loading the callee's type from the table, making it an immediate operand in the code instead.

• If the table is constant, check how many functions in the table have a given type signature. If it's smaller than some threshold, emit a "switch"-style sequence mapping table indices having that type to direct call instructions. In the special case where only one function has the right type this reduces to checking that calls of that type use the right table index.