Can MIR use interpretation phase to generate better code? about mir HOT 1 CLOSED

Since MIR can interpret code I was wondering if it is possible to have 2 phase compilation: interpret first, gather some profiling data and then generate machine code in second phase.

No. I don't think it is important to gather and use profile data automatically for MIR. It would be important for tracing JIT to form the right trace. But MIR is a method compiler. If you look at GCC benchmarks with and without feedback-directed optimization, the difference is not big (about 5-7%). More correctly it is big for compilers like GCC but not for simple MIR compiler.

I recently implemented a loop analysis which is used in RA to get BB frequency estimation. It is good enough although GCC uses another more sophisticated static frequency estimation algorithm.

What can be done is a decision when to JIT. It can be achieved through usage of a new interface. At the end of mir-gen.c there is simple implementation of lazy code generation of function (code generation by the 1st function call). It is only 5-10 lines of C code. It is easy to modify to generate and use code on n-th call.

The interface can be extended to collect also caller function which could be collected and used to generate code of the caller with inlining the calling functions (by using MIR_INLINE insn instead of MIR_CALL).

But I think it should be achieved by generation MIR code which will collect this info during execution (by interpreter and JITTed code). IMHO collecting and using frequency or call info is a simple case of speculation/deoptimization. For inlining we assume small number of calls and use MIR_CALL insn, if we found that there are many calls we use MIR_INLINE insn instead during generation of a new version of MIR. Dynamic languages will require more than this. For example, in CRuby JIT we can assume that Ruby VM plus insn works only with integer and generate a specialized MIR code for this with check. If the check failed, we generate new version of MIR code with general Ruby VM plus insn. We could start from opposite direction. In any case additional MIR insns should be generated to collect this info. There could be many ways of speculation (calling Ruby function, used object layout etc). MIR was designed to conveniently change version of MIR function numerous times. All function calls in MIR are implemented through a small code (thunk) which can redirect calls to different versions.

That is how I see the way currently to improve code by using a profile information.

from mir.