

Adding JIT-compilation to a toy interpreter - vmorgulis
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/jit/intro/tutorial04.html

======
DannyBee
So, while interesting work, and certainly an accomplishment i have a couple
problems with this (and i know it's alpha and not supposed to be used in
production, blah blah blah).

First and foremost, the language reference is not a language reference:
[https://gcc.gnu.org/onlinedocs/jit/](https://gcc.gnu.org/onlinedocs/jit/)

It tries to define operations by saying "it's analogous to C". But that's not
an actual thing. Either it's C or it's not C. If it's C, what language level
is it?

Does it actually have the same semantics as C? (The answer, from what I can
tell, is no, it has the semantics of GIMPLE, which is to say, 'random stuff
unless you set flags on DECL's, etc')

I could go on, but i would have much rather seen someone sit down, think about
what the JIT semantics were supposed to be, and build that, rather than take
GCC, and build a JIT out of whatever pieces happened to be laying around :)

For those who think is a lot of work, this is generally the right way around
to do it. You build the IR, then the compiler (or start building the IR, then
the compiler, and refine the IR as you discover you f'd it up).

2\. It has no real optimization pipeline management. About all you can manage
is the GCC options (both internal and external).

This is pretty bad. Again, normally you would start with a simple pass
manager, etc.

3\. From what i can tell, it only targets whatever arch you have compiled GCC
for in this case, which is usually "1".

To be frank (with no disrespect to it's author meant!), compared to something
like LLVM's JIT, this is at least 4-5 years of serious engineering work behind
(this includes all the work to do things like "define the semantics of the
IR", etc).

Again, to be frank, considering the alternatives, i have trouble seeing why
anyone would want to use this unless they were a serious free software
advocate.

It reminds me of the old joke about cygwin - the power of windows, the
interface of unix.

~~~
tptacek
Does it support all of GCC's targets? That'd be another reason to use it.

~~~
DannyBee
Not really. But this isn't about the JIT, GCC doesn't support all of GCC's
targets, and rightfully so. They couldn't if they wanted to :)

They have some primary and secondary platforms:
[https://gcc.gnu.org/gcc-4.9/criteria.html](https://gcc.gnu.org/gcc-4.9/criteria.html)

Primary platforms are what you care about. It means they won't do a release if
these have regressed.

The primary platforms are the usual suspects (and LLVM has backends for all of
them).

The secondary platforms are mildly interesting. LLVM has backends for those,
too. In GCC land, only the majority of tests have to pass for a release for
the secondary platforms.

The secondary platforms only have two arches over the primary ones:

s390 aarch64

This is a really long way of saying: I don't think it works on all targets, i
don't think it will ever work on all targets, and i wouldn't use it expecting
it does. If you stick to the supported platforms, you aren't buying anything
over the alternatives. If you don't stick to the supported platforms, why
start with GCC, when they aren't going to support it?

------
vmorgulis
A talk from David Malcolm (main contributor) about libgccjit (2014):

Slides:
[https://dmalcolm.fedorapeople.org/presentations/cauldron-201...](https://dmalcolm.fedorapeople.org/presentations/cauldron-2014/jit/#1)

Video:
[https://www.youtube.com/watch?gl=CA&v=XsaDtUkPu34&list=PLOGT...](https://www.youtube.com/watch?gl=CA&v=XsaDtUkPu34&list=PLOGTP9W1DX5U53pPxtWdKkyiqe3GAn6Nd)

------
tormeh
-march=native to the people! BTW, does anyone know whether the jvm compiles java code with processor-specific instructions i.e. beyond the common denominator amd64?

~~~
papercrane
Yes. For example, the hotspot VM can make use of AVX and AVX2 instructions if
supported by the CPU.

[http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee275...](http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/cpu/x86/vm/assembler_x86.cpp)

------
muehlbau
Is there a comparison between libgccjit and llvm in terms of compilation speed
and produced code quality?

