Operator table

[ghost]

There have been small disjoin mentions of an operator table for some time, but no central issue to discuss it.

Some use cases:

• An operator table could include values for immediate arguments to operators, such as the alignment and offset of memory access operators, or the arity on break operators, etc. This would allow the producer to use specialized short opcodes for high frequency operator patterns that match.
• An operator table could allow a choice for some arguments to be either sub-expressions, or immediate constants of the expected type, or immediate local variables in the expected type index space. For example, this would allow the producer to add specialized opcodes such as add-local-and-constant. With the post-order encoding a get_local of *.const does not know the expected type while decoding so has little chance to be of a predicted type, but by being able to bundle these into the opcode the type is known which allows a local variable index to use a type specific index space and an immediate constant to avoid redundantly encoding the type - these are very high frequency cases.
• An operator table could allow a choice to write the result(s) to immediate local variable(s). This makes an expressionless encoding style more efficient to encode because operators with results do not need a separate set_local.
• An operator table could allow a choice to discard the expression results of an operator. This would allow the producer to use store operators, and set_local, and call, and if and block operators that will consume less resources on the post-order expressions stack. This is not necessary for the expressionless code style, but is a natural option when using this style.
• An operator table could allow operator selection based on the type of the last local variable written which is likely the result type of the last argument of the current operator. For example, to select between i32.add i64.add f32.add and f64.add based on the last variable written. The producer would only emit these opcodes when the prediction matches, otherwise fall back to another more general opcodes, but this would likely handle the high frequency cases and do so with a smaller set of opcodes.
• As suggested in Expressionless encoding #669 the operator table might also give the option for some arguments to be omitted when immediate local variable indexes are predicted. This would help particularly in an expressionless style of code. Combining all the above would give some specialized short opcodes for high frequency cases, such as a single opcode call that accepts only an immediate function index yet reads and writes to local variables all predicted, or a short opcode to 'add a local variable plus immediate constant and write the result to a local variable and discard the expression result while selecting the operator type from the type of the last variable written and also predicting the local variable indexes'.

Cons:

• What would be the performance cost to the decoder in making so many dynamic decisions?
• Might decoders end up bundling straight line code for commonly used specialized opcodes and just patch a jump table. If so might the decoder performance be uneven across implementations, and would this even be significant?

[naturaltransformation]

#274 appears to be the main discussion thread covering this from before.