Re: On elisp running native

[Andrea Corallo]

Hi all,

this is the usual update for the activity of the last 2/3 weeks on the
native-comp branch.

- I did some reorganization of the passes and reworked the allocation
  strategy for the relocable objects to avoid duplication and save heap
  space.

- We now (finally) support multiple different builds on the same lisp
  code base.

  ~eln~ files are compiled in specific sub-folders taking in account
  host architecture and current Emacs configuration to disambiguate
  possible incompatibilities.

  As example a file ~.../foo.el~ will compile into something like
  ~.../x86_64-pc-linux-gnu-12383a81d4f33a87/foo.eln~.

  I've updated the load and 'go to definition' mechanisms to support
  this, so should be totally transparent to the user (if it's not is a
  bug).

  The same idea applies to all compilations, meaning main build as
  compiled packages.
  
- Optimize qualities (read compilation flags) are now stored in every
  ~eln~ file.  It's possible to inspect them for example as:

  #+BEGIN_SRC lisp
  (subr-native-comp-unit (symbol-function 'org-mode)) =>
  #<native compilation unit: 
.../emacs/lisp/org/x86_64-pc-linux-gnu-12383a81d4f33a87/org.eln ((comp-speed . 
2) (comp-debug . 0))>
  #+END_SRC

  We could store there other information we are interest in related to
  the compilation unit if we need.

- Finally I've set up a docker image for people willing to test it
  without having to configure and compile Emacs and libgccjit.  Now that
  I've learned how it works I plan to use it to setup a small CI to keep
  an eye that the latest GCC does not break with our build.

I've took note of all of this as Update6 in the usual page.

I'm generally very satisfied (surprised) about the stability of the toy.
I'm looking forward going into compile time mitigation.  I guess I'll
start this weekend with deferred compilation and GCC profiling.

Please let me know if there's some point I should address.

Andrea

-- 
address@hidden