Re: On elisp running native

[Andrea Corallo <akrl@sdf.org>]

Ergus <spacibba@aol.com> writes:

> Maybe a bit orthogonal to where the thread is going. But I have seen
> that libgccjit is in alpha stage and has been like that for years
> (according to the page). The source is included in gcc, but not compiled
> by default in any distribution. I don't find distributions providing it
> with the gcc bundle (I can ask for it's inclusion in arch, but I have no
> idea about the others).

AFAIK libgccjit is distributed by many (mosts?) distros including:
debian, fedora, ubuntu.

I guess this can easily improve further if Emacs choose to adopt it.

> Andrea, are you aware about the progress of the development of libgccjit
> and some estimation about when it is going to be stable? Because I can't
> ask for the inclusion of alpha libraries in the distros.
>
> Very thanks for this,
> Ergus
>

I don't know, in the last year I've up-streamed a bunch of patches to
extend it and keep it functional for gcc 9 and the upcoming 10 but I'm
not the maintainer.  As a consequence regarding the alpha classification
I have no precise info.  I invite you to ask on jit@gcc.gnu.org, I'll be
interested in reading the answer and I think is also important to
manifest the interest we have on that.

On the stability point: consider that libgccjit is a "relatively" thin
layer in front of the gcc pipeline.  In my experience I can tell you
that the buggynes of this layer can typically impact the guy how is
writing the code generator.  It means that if you are generating invalid
code and libgccjit does not catch it you'll get an ICE.  It can be
annoying (unless one likes to work into gcc) but is effectively more of
a developer problem and if happen typically does not impact the final
user and the stability of the shipped code.

I think for Emacs adopting the use of libgccjit would help gcc giving
momentum for keep on having a good jitter and Emacs for being able to
use this direct interface into gcc.  I see it as a win-win opportunity
for both and for GNU as a consequence.

That said if we decide to go for the other direction I've no problem in
investing some time to rewrite the final pass to target C instead.

Andrea

-- 
akrl@sdf.org