Write LIR documentation explaining design constraints.

[nbp]

Currently, it might seems opaque to a lot of persons why will HolyJit should use its own LIR representation instead of relying on LLVM IR or directly targeting Cretonne for doing transformations on the code extracted from the MIR.

The problem with existing projects is that it is hard to retro-fit new constraints on an existing compiler without rewriting large parts of the compiler.

In order to avoid mistakes our-self, we should explicit and document the constraints that we want on the LIR, on analysis and on transformation phases before implementing of it. The core idea is that HolyJit should be optimized for re-compilation.

Optimizing for re-compilation means that the compiler should minimize the time needed to re-compile after a de-optimization which invalidated the previously optimized code. This comes from the conclusion that the cost of a de-optimization is proportional to the cost of the re-compilation. Reducing the de-optimization cost implies that we can afford to do more speculative optimization, reducing the need for proves in the compiler in the early tiers of the JIT compiler.