Skip to content
A light-weight JIT compiler based on MIR (Medium Internal Representation)
C Other
  1. C 98.5%
  2. Other 1.5%
Branch: master
Clone or download
vnmakarov Remove MIR_GEN_DEBUG definition in mir-gen.c. Remove TEST_MIR_GEN.
Initialize debug_file in MIR_gen_init.  Finalize gen_ctx in
MIR_gen_finish. Replace MIR_GEN_DEBUG to MIR_NO_GEN_DEBUG.
Latest commit 58d9caa Feb 19, 2020
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github/workflows Change date/time to Moonday 22:40. Jan 27, 2020
adt-tests Add mir-mp-test.c. Nov 22, 2019
c-benchmarks Print average and geomean for c2m. Feb 19, 2020
c-tests Add 2 tests for issue36. Jan 21, 2020
c2mir Add option -dg to debug MIR-generator. Feb 19, 2020
include/mirc Use the same definition for int8_t as aarch64 system header files. Feb 13, 2020
llvm2mir Add option -dg to debug MIR-generator. Feb 19, 2020
mir-tests Replace MIR_GEN_DEBUG onto TEST_GEN_DEBUG. Feb 19, 2020
mir-utils Fix typo Jan 24, 2020
mir2c Change import to import_id in mir2c.c. Feb 3, 2020
.clang-format Add commented StatementMacros. Sep 2, 2019
.travis.yml Comment allow_failures. Jan 17, 2020
HOW-TO-PORT-MIR.md Add what to do at the end of porting. Feb 13, 2020
LICENSE Add year 2020 to Copyright. Jan 13, 2020
MIR.md Merge pull request #46 from ash-elangovan/fix_typos_mir.md Feb 8, 2020
Makefile Replace MIR_GEN_DEBUG onto TEST_GEN_DEBUG. Feb 19, 2020
README.md Update disclaimer for aarch64. Feb 15, 2020
mir-aarch64.c Save/restore sp/fp in _MIR_get_wrapper. Feb 14, 2020
mir-bin-driver.c Do not set C libs on osx Jan 24, 2020
mir-bitmap.h Add year 2020 to Copyright. Jan 13, 2020
mir-dlist.h Add unused attribute to functions. Jan 17, 2020
mir-gen-aarch64.c Move target_get_stack_slot_offset lower and fully rewrite to return t… Feb 14, 2020
mir-gen-stub.c Add generator stub file (target description interface of MIR generator). Feb 5, 2020
mir-gen-x86_64.c Rename HARD_REG_FRAME_POINTER to FP_HARD_REG. Feb 10, 2020
mir-gen.c Remove MIR_GEN_DEBUG definition in mir-gen.c. Remove TEST_MIR_GEN. Feb 19, 2020
mir-gen.h Remove MIR_GEN_DEBUG definition in mir-gen.c. Remove TEST_MIR_GEN. Feb 19, 2020
mir-gen.svg Update generator pass diagram. Nov 17, 2019
mir-hash.h Add year 2020 to Copyright. Jan 13, 2020
mir-htab.h Add unused attribute to functions. Jan 17, 2020
mir-interp.c Add !MIR_INTRERP_TRACE as guard for O2 optimize attribute. Feb 6, 2020
mir-ppc64.c Add year 2020 to Copyright. Jan 13, 2020
mir-reduce.h Remove unused vars. Jan 17, 2020
mir-varr.h Add unused attribute to functions. Jan 17, 2020
mir-x86_64.c
mir.c Rename reverse_branch_code to MIR_reverse_branch_code. Make it Feb 19, 2020
mir.h Rename reverse_branch_code to MIR_reverse_branch_code. Make it Feb 19, 2020
mir3.svg Update on aarch64 port. Feb 15, 2020
mirall.svg Make mir3.svg and mirall.svg better. Sep 10, 2019
sieve.c Add N_ITER and print the result. Oct 28, 2019

README.md

GitHub MIR build status GitHub MIR test status GitHub MIR benchmark status GitHub MIR Travis testing status

MIR Project

  • MIR means Medium Internal Representation
  • MIR project goal is to provide a basis to implement fast and lightweight interpreters and JITs
  • Plans to try MIR light-weight JIT first for CRuby or/and MRuby implementation
  • Motivations for the project can be found in this blog post

Disclaimer

  • This code is in initial stages of development. It is present only for familiarization with the project. There is absolutely no warranty that MIR will not be changed in the future and the code will work for any tests except ones given here and on platforms other than x86_64/aarch64 Linux/OSX

MIR

  • MIR is strongly typed
  • MIR can represent machine 32-bit and 64-bit insns of different architectures
  • MIR.md contains detail description of MIR and its API. Here is a brief MIR description:
  • MIR consists of modules
    • Each module can contain functions and some declarations and data
    • Each function has signature (parameters and return types), local variables (including function arguments) and instructions
      • Each local variable has type which can be only 64-bit integer, float, double, or long double
      • Each instruction has opcode and operands
        • Operand can be a local variable (or a function argument), immediate, memory, label, or reference
          • Immediate operand can be 64-bit integer, float, double, or long double value
      • Memory operand has a type, displacement, base and index integer local variable, and integer constant as a scale for the index
        • Memory type can be 8-, 16-, 32- and 64-bit signed or unsigned integer type, float type, double, or long double type
          • When integer memory value is used it is expanded with sign or zero promoting to 64-bit integer value first
      • Label operand has name and used for control flow instructions
      • Reference operand is used to refer to functions and declarations in the current module, in other MIR modules, or for C external functions or declarations
    • opcode describes what the instruction does
    • There are conversion instructions for conversion between different 32- and 64-bit signed and unsigned values, float, double, and long double values
    • There are arithmetic instructions (addition, subtraction, multiplication, division, modulo) working on 32- and 64-bit signed and unsigned values, float, double, and long double values
    • There are logical instructions (and, or, xor, different shifts) working on 32- and 64-bit signed and unsigned values
    • There are comparison instructions working on 32- and 64-bit signed and unsigned values, float, double, and long double values
    • There are branch insns (unconditional jump, and jump on zero or non-zero value) which take a label as one their operand
    • There are combined comparison and branch instructions taking a label as one operand and two 32- and 64-bit signed and unsigned values, float, double, and long double values
    • There is switch instruction to jump to a label from labels given as operands depending on index given as the first operand
    • There are function and procedural call instructions
    • There are return instructions working on 32- and 64-bit integer values, float, double, and long double values

MIR Example

  • You can create MIR through API consisting of functions for creation of modules, functions, instructions, operands etc
  • You can also create MIR from MIR binary or text file
  • The best way to get a feel about MIR is to use textual MIR representation
  • Example of Eratosthenes sieve on C
#define Size 819000
int sieve (int N) {
  int64_t i, k, prime, count, n; char flags[Size];

  for (n = 0; n < N; n++) {
    count = 0;
    for (i = 0; i < Size; i++)
      flags[i] = 1;
    for (i = 0; i < Size; i++)
      if (flags[i]) {
        prime = i + i + 3;
        for (k = i + prime; k < Size; k += prime)
          flags[k] = 0;
        count++;
      }
  }
  return count;
}
void ex100 (void) {
  printf ("sieve (100) = %d\", sieve (100));
}
  • Example of MIR textual file for the same function:
m_sieve:  module
          export sieve
sieve:    func i32, i32:N
          local i64:iter, i64:count, i64:i, i64:k, i64:prime, i64:temp, i64:flags
          alloca flags, 819000
          mov iter, 0
loop:     bge fin, iter, N
          mov count, 0;  mov i, 0
loop2:    bge fin2, i, 819000
          mov u8:(flags, i), 1;  add i, i, 1
          jmp loop2
fin2:     mov i, 0
loop3:    bge fin3, i, 819000
          beq cont3, u8:(flags,i), 0
          add temp, i, i;  add prime, temp, 3;  add k, i, prime
loop4:    bge fin4, k, 819000
          mov u8:(flags, k), 0;  add k, k, prime
          jmp loop4
fin4:     add count, count, 1
cont3:    add i, i, 1
          jmp loop3
fin3:     add iter, iter, 1
          jmp loop
fin:      ret count
          endfunc
          endmodule
m_ex100:  module
format:   string "sieve (10) = %d\n"
p_printf: proto p:fmt, i32:result
p_sieve:  proto i32, i32:iter
          export ex100
          import sieve, printf
ex100:    func v, 0
          local i64:r
          call p_sieve, sieve, r, 100
          call p_printf, printf, format, r
          endfunc
          endmodule
  • func describes signature of the function (taking 32-bit signed integer argument and returning 32-bit signed integer value) and function argument N which will be local variable of 64-bit signed integer type
    • Function results are described first by their types and have no names. Parameters always have names and go after the result description
    • Function may have more than one result but possible number and combination of result types are currently machine defined
  • You can write several instructions on one line if you separate them by ;
  • The instruction result, if any, is always the first operand
  • We use 64-bit instructions in calculations
  • We could use 32-bit instructions in calculations which would have sense if we use 32-bit CPU
    • When we use 32-bit instructions we take only 32-bit significant part of 64-bit operand and high 32-bit part of the result is machine defined (so if you write a portable MIR code consider the high 32-bit part value is undefined)
  • string describes data in form of C string
    • C string can be used directly as an insn operand. In this case the data will be added to the module and the data address will be used as an operand
  • export describes the module functions or data which are visible outside the current module
  • import describes the module functions or data which should be defined in other MIR modules
  • proto describes function prototypes. Its syntax is the same as func syntax
  • call are MIR instruction to call functions

Running MIR code

  • After creating MIR modules (through MIR API or reading MIR binary or textual files), you should load the modules
    • Loading modules makes visible exported module functions and data
    • You can load external C function with MIR_load_external
  • After loading modules, you should link the loaded modules
    • Linking modules resolves imported module references, initializes data, and set up call interfaces
  • After linking, you can interpret functions from the modules or call machine code for the functions generated with MIR JIT compiler (generator). What way the function can be executed is usually defined by set up interface. How the generated code is produced (lazily on the first call or ahead of time) can be also dependent on the interface
  • Running code from the above example could look like the following (here m1 and m2 are modules m_sieve and m_e100, func is function ex100, sieve is function sieve):
    /* ctx is a context created by MIR_init */
    MIR_load_module (ctx, m1); MIR_load_module (ctx, m2);
    MIR_load_external (ctx, "printf", printf);
    MIR_link (ctx, MIR_set_interp_interface, import_resolver);
    /* or use MIR_set_gen_interface to generate and use the machine code */
    /* or use MIR_set_lazy_gen_interface to generate function code on its 1st call */
    /* use MIR_gen (ctx, func) to explicitly generate the function machine code */
    MIR_interp (ctx, func, &result, 0); /* zero here is arguments number  */
    /* or ((void (*) (void)) func->addr) (); to call interpr. or gen. code through the interface */

The current state of MIR project

Current MIR

  • You can use C setjmp/longjmp functions to implement longjump in MIR
  • Binary MIR code is usually upto 10 times more compact and upto 10 times faster to read than analogous MIR textual code
  • MIR interpreter is about 6-10 times slower than code generated by MIR JIT compiler
  • MIR to C compiler is currently about 90% implemented

The possible future state of MIR project

Future MIR

  • WASM to MIR translation should be pretty straightforward
    • Only small WASM runtime for WASM floating point round insns needed to be provided for MIR
  • Implementation of Java byte code to/from MIR and LLVM IR to/from MIR compilers will be a challenge:
    • big runtime and possibly MIR extensions will be required
  • Porting GCC to MIR is possible too. An experienced GCC developer can implement this for 6 to 12 months
  • On my estimation porting MIR JIT compiler to aarch64, ppc64, and mips will take 1-2 months of work for each target
  • Performance minded porting MIR JIT compiler to 32-bit targets will need an implementation of additional small analysis pass to get info what 64-bit variables are used only in 32-bit instructions

MIR JIT compiler

  • Compiler Performance Goals relative to GCC -O2:

    • 70% of generated code speed
    • 100 times faster compilation speed
    • 100 times faster start-up
    • 100 times smaller code size
    • less 15K C LOC
  • Very short optimization pipeline for speed and light-weight

  • Only the most valuable optimization usage:

    • function inlining
    • global common sub-expression elimination
    • sparse conditional constant propagation
    • dead code elimination
    • code selection
    • fast register allocator with implicit coalescing hard registers and stack slots for copy elimination
  • No SSA (single static assignment form) for:

    • Faster optimizations for short optimizations pipeline and small functions (a target usage scenario)
      • Currently SSA could be used only for two optimizations (CCP and GCSE). SSA usage would mean 4 additional passes over IR. If we implement more optimizations, SSA transition is possible when additional time for expensive in/out SSA passes will be less than additional time for non-SSA optimization implementation
    • Simpler and more compact generator code because we can avoid to implement a lot of nontrivial code (for dominator and dominator frontier calculation, a good out of SSA code)
  • Simplicity of optimizations implementation over extreme generated code performance

  • More detail JIT compiler pipeline: MIR generator

  • Simplify: lowering MIR

  • Inline: inlining MIR calls

  • Build CFG: building Control Flow Graph (basic blocks and CFG edges)

  • Global Common Sub-Expression Elimination: reusing calculated values

  • Dead Code Elimination: removing insns with unused outputs

  • Sparse Conditional Constant Propagation: constant propagation and removing death paths of CFG

  • Machinize: run machine-dependent code transforming MIR for calls ABI, 2-op insns, etc

  • Find Loops: finding natural loops and building loop tree

  • Build Live Info: calculating live in and live out for the basic blocks

  • Build Live Ranges: calculating program point ranges for registers

  • Assign: priority-based assigning hard regs and stack slots to registers

  • Rewrite: transform MIR according to the assign using reserved hard regs

  • Combine (code selection): merging data-depended insns into one

  • Dead Code Elimination: removing insns with unused outputs.

  • Generate Machine Insns: run machine-dependent code creating machine insns

C to MIR translation

  • Currently work on 2 different ways of the translation are ongoing
    • Implementation of a small C11 (2011 ANSI C standard) to MIR compiler. See README.md
    • Implementation of LLVM Bitcode to MIR translator. See README.md

Structure of the project code

  • Files mir.h and mir.c contain major API code including input/output of MIR binary and MIR text representation
  • Files mir-dlist.h, mir-mp.h, mir-varr.h, mir-bitmap.h, mir-htab.h contain generic code correspondingly for double-linked lists, memory pools, variable length arrays, bitmaps, hash tables. File mir-hash.h is a general, simple, high quality hash function used by hashtables
  • File mir-interp.c contains code for interpretation of MIR code. It is included in mir.c and never compiled separately
  • Files mir-gen.h, mir-gen.c, mir-gen-x86_64.c, and mir-gen-aarch64.c contain code for MIR JIT compiler
    • Files mir-gen-x86_64.c and mir-gen-aarch64.c is machine dependent code of JIT compiler
  • Files mir-<target>.c contain simple machine dependent code common for interpreter and JIT compiler
  • Files mir2c/mir2c.h and mir2c/mir2c.c contain code for MIR to C compiler
  • Files c2mir/c2mir.h, c2mir/c2mir.c, c2mir/c2mir-driver.c, and c2mir/mirc.h contain code for C to MIR compiler. Files in directories c2mir/x86_64 and c2mir/aarch64 contain correspondingly x86_64 and aarch64 machine-dependent code for C to MIR compiler

Playing with current MIR project code

  • MIR project is far away from any serious usage
  • The current code can be used only to familiarize future users with the project and approaches it uses
  • You can run some benchmarks and tests by make bench and make test

Current MIR Performance Data

  • Intel i7-9700K with 16GB memory under FC29 with GCC-8.2.1

    MIR-gen MIR-interp gcc -O2 gcc -O0
    compilation [1] 1.0 (75us) 0.16 (12us) 178 (13.35ms) 171 (12.8ms)
    execution [2] 1.0 (3.1s) 5.9 (18.3s) 0.94 (2.9s) 2.05 (6.34s)
    code size [3] 1.0 (175KB) 0.65 (114KB) 144 (25.2MB) 144 (25.2MB)
    startup [4] 1.0 (1.3us) 1.0 (1.3us) 9310 (12.1ms) 9850 (12.8ms)
    LOC [5] 1.0 (15.0K) 0.53 (8K) 99 (1480K) 99 (1480K)

[1] is based on wall time of compilation of sieve code (w/o any include file and with using memory file system for GCC) 100 times

[2] is based on the best wall time of 10 runs

[3] is based on stripped sizes of cc1 for GCC and MIR core and interpreter or generator for MIR

[4] is based on wall time of generation of object code for empty C file or generation of empty MIR module through API

[5] is based only on files required for x86-64 C compiler and files for minimal program to create and run MIR code

MIR project competitors

  • I only see three projects which could be considered or adapted as real universal light-weight JIT competitors
  • QBE:
    • It is small (10K C lines)
    • It uses SSA based IR (kind of simplified LLVM IR)
    • It has the same optimizations as MIR-generator plus aliasing but QBE has no inlining
    • It generates assembler code which makes QBE 30 slower in machine code generation than MIR-generator
  • LIBJIT started as a part of DotGNU Project:
    • LIBJIT is bigger:
      • 80K C lines (for LIBJIT w/o dynamic Pascal compiler) vs 10K C lines for MIR (excluding C to MIR compiler)
      • 420KB object file vs 170KB
    • LIBJIT has fewer optimizations: only copy propagation and register allocation
  • RyuJIT is a part of runtime for .NET Core:
    • RyuJIT is even bigger: 360K SLOC
    • RyuJIT optimizations is basically MIR-generator optimizations plus loop invariant motion minus SCCP
    • RyuJIT uses SSA
  • Other candidates:
    • LIBFirm: less standalone-, big- (140K LOC), SSA-, ASM generation-, LGPL2
    • CraneLift: less standalone-, big- (70K LOC of Rust-), SSA-, Apache License
    • NanoJIT, standalone+, medium (40K C++ LOC), only simple RA-, Mozilla Public License

Porting MIR

  • Currently MIR works on x86_64 and aarch64 Linux and x86_64 MacOS
  • HOW-TO-PORT-MIR.md outlines process of porting MIR
You can’t perform that action at this time.