Timeline of next release

[dibyendumajumdar]

Hi @vnmakarov

I was curious if you have an idea how far away the next release is - and how far away the bbv branch is from being ready.

Regards
Dibyendu

[vnmakarov]

I still need to implement several things yet described in https://developers.redhat.com/articles/2022/02/16/code-specialization-mir-lightweight-jit-compiler. I'd like to implement debugging info generation but probably it will not happen for the next release.

There are some recent changes in my company. I can not spend half of my work time anymore on Ruby JIT and related MIR-project. Now I can work on MIR project only in my spare time. So my initial estimation was too optimistic but I am still planning to do this until the year end.

[dibyendumajumdar]

Thank you for the update.

I think what you have created with MIR is valuable, and I am glad that you continue to work on it, even if its in your own time.

I don't know if its possible but it might be useful to list the new features for next release somewhere and add a status to them. Maybe in the bbv branch README file?

I am not waiting for this release however, but it is useful to know what features to expect and how we may exploit those features.

BTW I reread that article above. One the extensions proposed - __builtin_prop_cond - is kind of redundant IMO as this can easily be coded by the user of MIR? For instance, in Ravi, I track the types of values and generate type specific opcodes when I know the types.

[vnmakarov]

Actually in CRuby I also did code specialization on bytecode level including basic block versioning which probably you do not do in your implementation. BBV is a powerful technique of zero-cost specialization. For example, for the following case

a is int  b is float
\         /
 \       /
  \     /
  BB1: use of a

BBV creates 2 versions of BB1 with incomming integer a value and float a value.

So specialization is common part of dynamic language JIT compilers and it would be nice to have a JIT supporting this.

But I'd like to go further and implement support in MIR to implement meta JIT compiler: an automatic JIT compiler implementation from the interpreter by annotating code for bytecode interpreter. Finally, I'd like to implement meta-tracing JIT compiler support. Such JIT will do automatic code specialization and forming frequently exected traces and optimizing code for them. Properties are an important part for this.

Again all of this is described in one my blog post https://developers.redhat.com/articles/2022/02/16/code-specialization-mir-lightweight-jit-compiler

You are right I shoudl update README.md for bbv branch as there are a lot of new features:

• variable bound to machine registers
• new builtin __builtin_expect in c2m and int overflow related MIR insns and corresponding builtins in c2m
• indirect jumps in MIR and label as values extension for c2m
• properties and basic block versioning based on them
• significantly rewritten generator with new optimizations and new more sophisticated RA and usage of non-conventional (as before) SSA
  • This improved generated code quality from 0.89/0.82 (average/geomean) to 0.98/0.91 of GCC -O2 on my tests
• There are also some simplifications:
  • I dropped ppc64 BE support as it is used only for old ppc64 machines (power7 and lower)
  • I removed parallel function code generation (although c2m driver still support parallel parsing of different C files):
    • as I found that it does not fit well with lazy function and bbv code generation
    • for dynamic languages heavely used on servers (like RoR instances) when all CPUs used it has a little sense
      and even worse as some CPU time spent on thread syncronization
    • so a user of MIR, if he wants, should implement parallel function generation by himself using different contexts

That is what I remember right now but I am sure I forget something.

[edubart]

Now I can work on MIR project only in my spare time.

I also think what you have created with MIR is very valuable. Since your original plans have shifted, maybe you should also change the strategy for MIR, to keep it manageable with the shorter amount of time you have. I feel that MIR is very usable already. I would suggest trimming down the original features, to make it less ambitious, so there is less big amount of work to do, and maybe do more frequent releases with small features and bug fixes.

I look forward for the day "This code is in initial stages of development" message is gone, bbv branch is merged and MIR is officially considered somewhat stable.