

Libgccjit.so: an embeddable JIT-compiler based on GCC - crncosta
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00228.html
I saw this at proggit[1].<p>The gccXllvm competition have been good for both parts, IMO.<p>[1]http:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;programming&#x2F;comments&#x2F;1nn6p3&#x2F;libgccjitso_an_embeddable_jitcompiler_based_on_gcc&#x2F;
======
jordigh
This is very exciting news for GNU Octave.

One of the things in which Octave is much slower than Matlab is in looping.
Matlab used to have this slowness too until they started JIT compiling their
loops. For Octave, this has been more difficult, and the only tool that we've
had for accomplishing this has been LLVM.

While our JIT compiler code is still very much alpha, it has already been
quite a pain to deal with the LLVM JIT "API" because the truth is, they don't
really have an API, i.e. no promise of stability. Every LLVM release has
broken everything and our code keeps having to change in order to accomodate
all of those changes. Every. Damn. LLVM. Release.

I don't know how stable the JIT API for gcc will be, but already it's starting
to look much better and thought-out as a public API. Here's hoping that our
fellow GNUs-in-arms can help us make a faster and better Octave!

~~~
pwnna
Yes! This will be a serious plus for Octave as it stand right now.

------
georgemcbay
This is pretty cool but even when it is more robust and works with optimized
code I think most developers looking for something like this are far more
likely to choose LLVM for licensing reasons.

Current gcc is GPLv3 and that is very unlikely to change, if you link your
project to this you are thoroughly "infected" by the GPL since unlike many GNU
projects that are explicitly meant to be linked to by your own projects, gcc's
core is not LGPL and the runtime library exemption granted by gcc is not
sufficient to save you from infection in this use case.

~~~
riotingpscifis
Unless you are extending the compiler why would you care? GCC consistently
produced faster code that LLVM

If you are extending the compiler, why would you want to allow companies like
apple and oracle to bottle up you hard work and not give anything back? Either
by not giving the code back or by patenting parts of the functionality they
add and then suing you when you try and use them.

~~~
MichaelGG
It's not LGPL, so linking to it means your entire project is now GPLv3.

~~~
belorn
And? The above post asks why companies need to make proprietary code changes
to the _compiler_ , or why the community should allow distributors of GCC to
patent parts of the compiler and then go suing users who the distributer gave
copies to.

~~~
georgemcbay
Even if you don't make changes to the compiler, if you link to this project
you are GPLv3 infected. You simply can't use this without exposing your entire
project to GPLv3 infection, the usual LGPL and/or runtime library exceptions
don't apply to gcc's core code because it was never intended to be used as a
library.

Let's say you have an existing FOSS app that is BSD or MIT licensed and it has
its own built-in scripting language. You'd like to build a JIT for that
scripting language, you see this library and decide to use it in your project,
well... you can't do that without changing your entire project to GPLv3 terms
because the combined work created between this and your own code all has to be
available under the GPLv3 terms. This is usually solved by making the relevant
parts of the project LGPL or granting a runtime library exception but neither
of those applies to the core gcc code, so the GPLv3 infection in unavoidable.

Whether or not that issue is important is open to debate and depends upon your
software politics, but in practical terms it means very few people will use
this in their project unless they are already GPLv3 committed for some reason.

------
hartror
I wonder if this would have been easier to accomplish with LLVM given that
gcc's api is so notorious to deal with?

~~~
dmytrish
It looks like LLVM was designed for JIT compilation from the start.

~~~
DanWaterworth
LLVM doesn't make a great JIT compiler and I don't think gcc will either. The
problem is that, most of the time, your JITed code won't be used very much and
so the amount of time that it takes to generate it is a significant proportion
of the total execution time.

LLVM and gcc are optimized for producing the fastest possible code and will do
so at the expense of spending more time doing it. That's not to say that they
can't become great JIT compilers in the future, but I don't think we're there
yet.

~~~
jevinskie
LLVM understands this issue. That is why they have "regular" instruction
selection passes and "fast" instruction selection passes. The JIT uses
FastISel. But you are definitely right, it is not anywhere near as lightweight
compared to, say, Hotspot.

~~~
sanxiyn
There is also an issue of FastISel not supporting the full LLVM IR, so if you
depend on FastISel for fast JIT, you basically need to design LLVM IR
generation around that, limiting yourself to undocumented, unspecified, and
ever changing subset of LLVM IR. Which can be done, but not very pleasant.

~~~
DannyBee
Right, but unlike GCC, this is not an architectural issue, but a simple
implementation issue that could be fixed.

~~~
azakai
It's an implementation issue, but it is far from simple.

~~~
DannyBee
So I guess I disagree. There are known good solutions to this problem. Yes,
it's definitely some work actually writing the code right, but it's not like
this is a problem that requires engineering brand new solutions. It just
requires a good engineer and some time.

I consider that "simple", as on the scale of "engineering complexity", it
would be simple, even though on the scale of "engineering time" it may take
longer.

------
rzw
David is well known in the Python circles. This should be interesting!

