So there will only be an "untyped add" instruction, and that
instruction will dispatch at runtime to do the right thing? That seems fine for the "high level" IR (because it directly corresponds to the JS semantics).
There would be only one add instruction, which would allow several different combinations of operand types, one of these being "all operands boxed", another being "two 16 bit integers", another being "two float64 values", etc. The instruction would also set its own output type based on the operand types.
When converting the AST, it only boxed adds would be produced. The semantics of the boxed add would be defined in terms of other instructions, including, say, 32 bit integer adds. So there would still be many different add instructions, just like now, but in terms of IR, all these instructions would be represented by the same class, with different input/output value types.
I have an unrelated question. What are the allowed operands of IR
operations like "add"? Is it always a temporary, or can it also be a constant? Anything else?
The operands are either SSA temporaries or a constant value. An SSA temporary is always the output of another instruction, which is why I introduced the "arg N" pseudo-instructions in the CFG, to have a way of referring to input arguments to a function as the output of some instruction. The IR is not low level enough to allow directly adding memory values. A value in memory has to be loaded into an SSA temporary before it can be added. This is also inspired by LLVM:
http://llvm.org/docs/LangRef.html#binaryops
- Maxime