I've started a refactoring of the IR instructions code. I implemented a function called GenericInstrMaker, which constructs a closure to be used as an instruction constructor. This is meant to be a quick way to create new "classes" for instructions that follow a generic pattern (eg: all arithmetic, comparison, bitwise, logical operators).
Erick and I have also been discussing introducing some x86 instruction classes into the IR for code generation and register allocation purposes, which made me think it would be nice to have an "X86Instr" class in our instruction class hierarchy. However, this somewhat breaks my current model, because, some x86 instructions will be branch instructions, but these can't have both X86Instr and BranchInstr as their prototype.
Hence, I've been thinking that perhaps, instead of having a BrancInstr class, all instructions should have an "isBranch" boolean flag. I was also thinking that instructions could have other flags, such as a "write" flag, and a "read" flag, to indicate that some instructions have memory access side effects. These side effect flags would be useful for writing an IR optimizer, later on.
Any comments on those ideas?
- Maxime