Re: On elisp running native

[Stefan Monnier]

> What do think about the general idea of having a compiler able to native
> compile elisp?
>
> What do you think about the proposed design (Lisp -> LAP -> LIMPLE ->
> libgccjit -> elf)?

I think the general design is quite sound, yes.

> Do you see any weakness in some part of the design you would be
> particularly worried about?

- 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.

- Going through the byte-compiler's LAP code is convenient but not
  ideal.  Eventually, you'll want to circumvent bytecomp.el and write
  fresh new code to go from Lisp to LIMPLE without the detour through
  a stack machine (and probably not in a single step either).
  It's not a source of *worry*, tho.

> Do you see in this a potential for having it up-stream in the future?

Yes, tho it will take time.

The main benefit of such a compiler is not to run existing Elisp code
faster (99% of existing Elisp code runs fast enough that the user won't
notice if it runs faster) but to make it practical to write *other*
Elisp code which would otherwise be too slow.  But for that to work
well, you want the new compiler to be available "everywhere", rather
than just on some platforms.  So it will only start being useful when it
works on GNU/Linux, macOS, Windows, ARM, RISC-V, x86, amd64, MIPS,
younameit (AFAIK lbgccjit's CPU coverage is already good enough for
that, so the main barrier here is the OS support), and when it's not
just an option at compile-time but when it's included in all builds.

So, first it will take time for the compiler to work in all these cases,
then for the feature to be enabled by default, and then for code to
start making actual use of it.


        Stefan