I just completed the refactoring of the if instruction and verified that all unit tests pass in 32 bits. This is now committed. Erick, you should be able to merge without too much difficulty. The difference in the back-end is that the new if instruction code generation replaces the old if instruction and the comparison instructions.

The code for fib is as predicted, except for a boxToBool that has been inserted. I will look tomorrow into optimizing the code generation to make it a bit faster and avoid inserting useless boxToBools and phi nodes when possible.

I also want to look into having an support for (x & y === z) in the if instruction, but I believe it might be best to wait until the new register allocator interface is ready, as this might take more than one scratch register to implement.

On this topic, Erick, I'd like to discuss the new register allocator interface with you (and Marc?) when you have time. I think that we may want our register constraints to be specified by a function, rather than fixed ahead of time... Because, for example, some instructions may need a varying number of scratch registers depending on how many operands they have, or on their type. In any case, it would be worth it to brainstorm about such issues. In the end, this new interface should make the code generation simpler and more robust, while generating higher-quality code.

Next week I will probably look into using graphviz to visualize CFGs. This might help discover some potential CFG optimization patterns and/or generate pretty graphs for future publications.

- Maxime