Re: On elisp running native

[Andrea Corallo <akrl@sdf.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> - Beside the issue of portability/availability of libgccjit, there's
>   also the issue of stability of libgccjit.  More specifically, what is
>   the probability that libgccjit will still exist more or less in the
>   same form in 10 or 20 years?  So far GCC's main entry point has been
>   the command line, so we can expect that running `gcc` will still
>   work 20 years from now.  Similarly, LLVM's main entry point is
>   an API that builds a kind of CFG representation of code, so we can
>   expect that to still exist 20 years from now.  But to the extent that
>   libgccjit is not very widely used, there's a risk it will completely
>   disappear or change radically, especially since we use it here in
>   a way contrary to what its name ("...jit") suggests.

Libgccjit is modeled following a C-like semantic, I guess because plugs
where a conventional Gcc front-end would.  Consequently I've no reason
to think this should change but yes... this is not a strong proof I get
it.

Probably this is more relevant:

https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html

When a new entry point is added this is always just and additive change
to the API.  At least this is the policy I understand and follow if I
work into it.

>   a way contrary to what its name ("...jit") suggests.

That's an interesting point.  I think the only two differences from the
"typical" jit use to the one we do are:

  - We never leak pointers as immediate into the generated code.

  - We do not ask libgccjit to perform the library load cause we do it
    with our machinery.

And this let me think to Eli's point on windows missing compatibility.
There's good chance that the reason for this is that libgccjit does use
dlopen&friends.  Actually these are exactly the features of libgccjit
infrastructure we do *not* use.

I've decided to use libgccjit cause I thought was the nicest technical
solution.  (admittedly quite GNUish :)

One could potentially write another final-pass targeting C from LIMPLE.

Thanks for the feedback.

Andrea

--
akrl@sdf.org