GCC JIT vs others JIT ....

[David Malcolm]

On Tue, 2013-10-22 at 20:30 +0200, Basile Starynkevitch wrote:
> Hello David Malcom and all,

Hi Basile.

> I am trying to understand what are the conceptual differences between
> GCC JIT (when it will be mature enough) and other JIT libraries like GNU
> lightning http://www.gnu.org/software/lightning/ or LLVM
> http://llvm.org/ or GNU libjit http://www.gnu.org/software/libjit/ from
> the point of view of the developer using the JIT library.

I was aware of lightning and LLVM; I wasn't aware of libjit - thanks for
the link.

My interest is in modularising GCC's code, and I've been working for the
last few years on dynamic language runtimes (for Python), so turning GCC
into being usable for JIT use-cases is of great interest to me.

I tend to prefer fixing existing code over rewriting, hence my
preference for generalizing GCC to cover JIT workloads, over having a
separate JIT project: I'd prefer to have code shared between the
ahead-of-time compiler and the JIT compiler.  But other people may feel
differently, of course.

> GNU lightning is probably much lower level than GCC JIT. It probably has
> the advantage of generating quickly rather slow machine code. It mostly
> gives a small set of register like variables.

>From what I've seen of lightning it does indeed seem to have a much
lower level API compared to libgccjit.  It's probably faster: certainly
libgccjit isn't fast yet - for example, internally we're writing out
a .s file to disk, and then having to invoke other tools as subprocesses
to get that into a form we can execute.   I hope to eventually eliminate
that kludge (e.g. turn the GNU assembler into a library and use it
in-process, or perhaps even have GCC's RTL level directly emit machine
code instead of asm).  I deliberately hid the kludge behind the API, so
it should be possible to fix it without affecting ABI.

It's possible to see timing data by setting the bool option

   GCC_JIT_BOOL_OPTION_DUMP_SUMMARY

on the context; this is (very) roughly equivalent to running cc1 without
the -quiet option.

> LLVM probably is the equivalent competitor, since both GCC JIT and LLVM
> are derived from ahead of time compilers (of course, for LLVM it was
> initially not much true). So probably both GCC JIT and LLVM would
> produce, a bit slowly, some good machine code. (In particular because
> GCC JIT is, AFAIK, emitting assembly code).
(nods)   Yes, as described above, libgccjit does currently go through .s
files internally.
(my understanding of LLVM's origins are that it was for an ahead-of-time
compiler for doing a radical whole-program optimization that implements
pointer compression automatically)

> BTW, I have no idea if GCC JIT has some option to set the optimization
> level.

It does:

  gcc_jit_context_set_int_option (ctxt,        
                                  GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL,
                                  3);
is equivalent to "-O3" i.e. -O0 through -O3 are selectable.

0 is the default.   The API is simple for now.  I can add options for
enabling specific optimizations if people want, perhaps customization of
the pass pipeline (I implemented the pass_manager code in gcc 4.9 which
may help us to support such a use-case).

> Libjit seems superficially similar in terms of API (to both LLVM and GCC
> JIT): it offers a mini-C like intermediate representation.

Yes, looking at the API it looks similar to the API I came up with,
though I have rvalues vs lvalues, and there are no explicit blocks, only
label placement (you can always implement blocks by placing labels).

> I also believe that GCC JIT is probably the JIT library which runs on
> much more processors than others (because GCC has a wide set of
> targets).

I'd agree with that, though I'm speculating.  This is one of the reasons
for the very high-level nature of the API.

I'm conscious that I've only used the API to implement a method JIT, not
a tracing JIT; we may need additional constructs to help deal with the
kinds of dynamic code patching that a tracing JIT needs to do.

> David, do you think that a libit based JIT engine could quickly switch
> to GCC JIT once it has matured? I am guessing it would be quite easy.

I think so.

Out of interest, are you thinking of using this for MELT?  i.e.
embedding libgccjit inside a gcc plugin?  If so, I wonder if there could
be nasty interactions between the two copies of the GCC code?  libgccjit
has a symbol map that hides everything other than the 50 or so gcc_jit_*
entrypoints, so hopefully the two copies of the code would peacefully
coexist within the same address space - but it sounds like something to
be wary of.

Hope this is helpful
Dave