gccemacs

There was (and still is) a compiler calledCMUCL(Carnegie Mellon University Common Lisp) withlong rootsin history.

CMUCL is based on thePython compiler(named before the programming language), now used also by its "modern" descendantSBCL.

This futuristic compiler introduced for a programming model where not only the compiler is able for diagnosing issues at compile-time, but a dialogue with the programmer can be established in order for the second to improve the code where the compiler could not generate efficient code for some reason.Herea nice blog introducing some of this.

Both CMUCL and SBCL are still known for their powerful type inference capabilities.

We can list some valid reasons why an effective inference engine can be beneficial when compiling a dynamic programming language:

Before this rework the compiler was able to propagate for each variable only a value or a simple type, and it did not take into account type hierarchy.

Now we aim to be able to propagate what we can express with a Common Lisp style type specifier (well, say a subset).

A type specifier represents a set (finite or not) of values and in Elisp it translates to something like:

integer=> an integral number

float=> a floating point number

number=> an integer or floating point number

atom=> all atoms

t=> everything

nil=> nothing

(function (number) string)=> a function taking a number as argument and returning a string

We can also have type specifiers describing specific values or ranges:

(member foo bar baz)=> a symbol amongfoobarorbaz

(integer 2 4)=> an integer among 2, 3, 4

(integer * 1)=> an integer less than 1

We can combine all of these with boolean operators as:

(or symbol integer)

(or (integer * 0) (integer 10 *))

(and sequence (not string))

Etc…

Note this notation is capable of identifying set of values as well as the special case of the single one, so this (or its representation) is what we want to handle and propagate inside the compiler!

We have listed different ways in which a clever inference can be beneficial, a specific one is the ability to derive function types automatically. At the moment, I've exposedsubr-typeand every (elisp/l) native compiled function will have a type specifier accessible there.

I've spent quite some time toying and writing tests so here are some examples to give a flavor:

(defunfoo(x)
x)

Once native compiled one can get foo's type as:

(subr-type (symbol-function #'foo))

;;=> (function (t) t)

(defunfoo(x)
(ifx
1
3))

;;=> (function (t) (or (integer 1 1) (integer 3 3)))

(defunfoo(x)
(ifx
'foo
3))

;;=> (function (t) (or (member foo) (integer 3 3)))

Integer range propagation

(defunfoo(x)
(when(> x 3)
x))

;;=> (function (t) (or null float (integer 4 *)))

Constant propagation

(defunfoo(x)
(let((y 3))
(when(> x y)
x)))

;;=> (or null float (integer 4 *))

(defunfoo(x)
(when(> 10 x 3)
x))

;;=> (function (t) (or null float (integer 4 9)))

Logior is known to have(or marker integer)as parameters

(defunfoo(x y)
(setfbar (logior x y))
y)

;;=> (function (t t) (or marker integer))

The range is propagated across the+function.

(defunfoo(x y)
(when(and(> x 3)
(> y 2))
(+ x y)))

;;=> (function (t) (or null float (integer 7 *)))

(defunfoo(x y z i j k)
(when(and(< 1 x 5)
(< 1 y 5)
(< 1 z 5)
(< 1 i 5)
(< 1 j 5)
(< 1 k 5))
(+ x y z i j k)))

;;=> (function (t) (or null float (integer 12 24)))

(defunfoo(x)
(if(not (integerp x))
x
(error"Ops"))))

;;=> (function (t) (function (t) (not integer)))

(defunfoo(x)
(cond
((not (integerp x)) (error"Ops"))
((> x 100) 'big)
((< x -100) 'small)
(t x)))

;;=> (function (t) (or (member big small) (integer -100 100)))

Despite trying to provide similar inference capabilities, the Emacs native compiler and Python differ per construction and used internal representation. This can lead to different and interesting results.

(defunfoo(x)
(let((y 'bar))
(setfy 100)
(ifx
(setfy 1)
(setfy 2))
y))

In this case SBCL forecasts as return type(OR (MEMBER COMMON-LISP-USER::BAR) (INTEGER 100 100) (INTEGER 1 2)),note that bothbarand100indeed can never be returned. Apparently when local variables are reassigned Python is falling back on listingallpossible values that a variable may assume during execution.

This might be quite a relevant limitation for a not very functional programming language as Elisp.

In contrast in the Emacs native compiler the propagation happens in the SSA lattice with precise analysis of each variable at any point of the control flow graph, the forecasted return type is then only (integer 1 2).

Another interesting case is code like the following:

(defunfoo(x)
(unless(or(eq x 'foo)
(eql x 3))
(error"Ops"))
x)

SBCL forecasts a return type ofTwhile we identify that the function can only return(or (member foo) (integer 3 3)).

This is not to say that Emacs compiler is superior, there's still a lot to do and I'm sure there are many corners where Python does better, but I believe being based on a "modern" representation as SSA is a solid foundation to start with.

For who's interestedthis blogdiscuss more in depth some of Python's limitations.

Where does the compiler get the value/type information to be propagated in the control flow graph?

• For each conditional branch testing a value produced byeq eqlequal=dedicated constraints are placed in the target basic blocks to express the result. Constraining a variable translates in a set-like operation as union, intersection or negation.
• Similarly we constrain integer ranges when testing with>>= <<=.
• Again we constrain variables for type when they are tested using a known type predicate.
• We propagate integer ranges across arithmetic functions (ATM+ and-). Read(1+ (integer 1 2)) => (integer 2 3)
• We rely on known function type specifiers for corresponding function return values.
• Similarly we can constrain function arguments. For example, after calling(int-to-string x)in the CFG we can assumexbeing a numberbecauseint-to-stringtype is know to be(function (number) string)).

So yes, to feed the inference engine I enjoined writing ~300 type specifiers for built-in and pure functions. These ATM are in comp-known-type-specifiers.

The compiler cannot rely on other function types derived by the compiler as these indeed might be redefined.

The code went progressively in the last couple of months, still a number of things needs to be done:

• Propagation is at the moment disabled on functions catching non local exists.
• Still need to expose these type specifiers throughcl-the.
• There's currently no API to manually declare (declaim?) function types, same parameter type declaration inside functions has to be done.
• The system is currently limited to built-in types, not by construction but needs to be done. I think this should give sensible speed-ups especially for code with many structure slot accesses.
• No diagnostic is emitted based on inferred value/types.

On my system ATM I have about 4000 functions loaded where the derived return type is something more interesting thant,this is about the 20% of the total. Such number might increase in the future if the system improves, if we describe more primitives to the compiler and/or more functions are declaimed by users and if more dynamic code get ported into lexical.

So yeah this should be the foundation for other optimizations to come (Ex. unbo xing ).

Ah! Happy new year:)

Fast bootstrapis now active by default. A new control has been added calledNATIVE_FULL_AOTto force full Ahead-of-Time native compilation of all Emacs. This supersedesNATIVE_FAST_BOOTand effectively works as this last being negated.

To force full Ahead-of-Time compilation:make NATIVE_FULL_AOT=1.

In the seek of making compiler type hints usable I've done some initial work to expose these through the available Common Lisp extensions we have.

cl-thenow understandsfixnumandcons.

Ascl-thedecides to emit the type check based on cl--optimize-safetyandcl--optimize-speedI needed a way to synchronize the latter withcomp-speedand to have these effectively set. I addedcl-optimizeas a defun declaration as this is function context aware.

I've also added a benchmark calledinclist-type-hintsto the elisp-benchmarksthat re-implements the originalinclistmaking use of type hints.

As an example this what it looks likes:

(defunelb-inclist-th(l)
(declare(cl-optimize (speed 3) (safety 0)))
(prog1l
(whilel
(let((c (cl-thecons l)))
(cl-incf(cl-thefixnum (car c)))
(setql (cdr c))))))

On my machine the originalinclistbenchmark runs in1.59sand the newinclist-type-hintsin0.75sthat is about twice as fast.

I've up-streamed in GCC the libgccjit support for static initialized arrays and installed the corresponding code on the Emacs side to make use of this feature when available.

This new entry point will come with GCC 11 and as we discussed in Compile timethis should help marginally with the current Emacs load time and in the (far) future may allow us for removing the current workaround we have in Emacs. That said I also suspect may become crucial the day we get a faster de/serializer and we make use of it the.elnload machinery.

Sweets come lasts. This activity tackle one of the last source of incompatibility we had against the vanilla implementation that was primitive advising.

As you may know the native compiler tries to emit direct calls to primitive functions to avoid going through thefuncall trampoline, and it tries to do that for every primitive including the ones without a dedicated op-bytecode.

As this is extremely effective performance wise unfortunately it made advice uneffective for all primitive functions called from native compiled Lisp.

Now the manualwarn againstthe primitive advice practice for two reasons:

• Primitives maybe called directly from C and there's no way the advice will be effective in that case.
• Circularity with the advice mechanism.

The manual does not mention that (as technically it falls into the first point) but has to be noted that the byte interpreter will call directly all primitives with a dedicated op-bytecode again ignoring advices. Therefore as an example advising function+ will be effective only on interpreted Lisp but not on byte-compiled one!

Now apparently advising primitives is a very bad practice and no one should go for it,butin reality I can tell you that a ton of packages just do that as typically works for many primitives.

The current workaround was to have a list of primitives commonly advised and use this to prevent optimizations on these. Quite a weak approach as regularly some package showed-up advising some primitive not in the list.

The following mechanism is what we came-up with to fix the problem, say we want to advice thedelete-fileprimitive:

• A trampoline function similar to the following is synthesized.

  (defun--subr-trampoline-delete-file(filename&optionaltrash)
  (funcall filename trash))
  

• This function is native compiled (without performingfuncall trampoline removal!). Note also that the expose ABI is exacly the same of the original primitive.
• Once this function is loaded the function pointer to this function is used to replace the primitive one in thefunction link table.

The result of this procedure is that each newly activated function will use the trampoline in place of the original primitive and the trampoline will execute the call going throughfuncallmaking the advice effective!

This works so well that in-fact now is even possible to advice effectively what wasn't effective in byte-code (ex the+ function). But hey,don't try this a home!

Compiled trampolines are stored in the eln cache directory and re-used for following sessions without requiring further compilations.

Now what's so important about the last item? Well just this was the lastone in my list of compatibility issues!

This obviously doesn't mean that now it's all perfect or done, but it means that if a package is not behaving correctly I'll be very interested into looking into it because a priori I've no idea why it should not work correctly.

Integrating the native compiler with Emacs has been averylong and non straight forward task, so I feel quite relieved thinking the most is done and things are in the right direction.

A question raise that is "what's next"? Here my plans:

• Clean-up what's left on the bug tracker and have a look for some code clean-up.
• Collect any feedback regarding some requirement that may be left for upstreaming.
• Happily restart working in the compiler itself to improve it further.

Looking forward!

Deferred compilationis now enabled by default, therefore is not anymore necessary to setcomp-deferred-compilationmanually.

When a.elcfile is being loaded if a suitable.elnfile is found in one of theeln-cachedirectories this is loaded instead. Otherwise the file is compiled asyncronously and its definitions are swapped once finished with that.

I've removed.elnfromload-suffixesas loading native code is not supposed to be manually done by the user. This has also the positive side effect to reduce the number of files we search for while performing a load.

A new global variable is definedcomp-eln-load-path.By default this is a list of twoeln-cachedirectories. On my installed Emacs looks like:

( "~/.emacs.d/eln-cache/" "/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/eln-cache/" )

The first one is in use by the user for new compilations while the second one is for.elnfiles compiled during the build process.

Eacheln-cachedirectory has a structure of this kind:

~/emacs$ tree eln-cache/
eln-cache/
└── x86_64-pc-linux-gnu-918495e2956ca37e
├── abbrev-a99d112c152dc4841918bf4ba7134a3345ff6ba5ae5548b6ad8c0098b169ddf5.eln
├── autoload-485c4a0aa35fee71d840229c24a2663ea75ab150df53c33d65bb19c50d864430.eln
├── backquote-613030c141e05318757ad8d32f6876fa6a7dc493d67ed5b940fa5c484739d955.eln
...

The additional directory layer insideeln-cacheit's used to disambiguates triplet and Emacs configuration. Each.elnfile has a name constructed with an hash to match the original source file.

New compiled files are deposed always in the first entry of comp-eln-load-path.

You can delete anyeln-cachefolder as files will be recompiled when needed with the exception of the last entry in comp-eln-load-path.This is to be considered theeln system cache directoryand contains files necessary for a native compiled Emacs to start-up.

You can still monitor if you wish the compilation activity in the *Async-native-compile-log*buffer. If you want to check interactivelly that a function is effectively native compiled you can still useC-h forM-x disassemble.

About three weeks ago I've merged support for native compiling dynamic scoped Elisp. After some (expected) necessary fi xing now every thing seems to be working correctly.

The native compiler is now able to compile every.elfile given as input and the amount of native code compiled in Emacs is roughly doubled.

"It's a long way to the top…"and the same is for completing this integration job. So I took quick digression back into performance.

Thisinteresting discussion lead to a broader and unified definition of which functions in Emacs Lisp are pure. This advantage both byte and native compiler but the second one especially given the nature of its propagation engine.

Having now at disposal a bigger set of primitives pure functions to begin with and having implemented the mechanism to fetch function pure declaration, I thought was interesting to implement a small inter-procedural analysis pass to infer automatically other pure functions not explicitly declared as such.

Given pure functions when possible gets executed in the compile time making ineffective subsequent redefinitions, this pass is gated atspeed 3.

It was fun to see that three of the u-benchmarks gets completely optimized out and are executed now in zero time.

One could argue that these u-benchmarks are too simple and now we need more complex ones, and yes he's right:)

Compile time is reduced of about a factor 5!

I was suspecting part of the issue of the considerable compile time had to be related to how we stored constant objects into the compiled code. This assumption was coming from the observation that compilation units with a lot of objects had higher compile times.

I wrote a GCC patch to enable static data initialization with libgccjitand when I first tested it I was surprised in how faster compiling the branch was.

As a counter measure we came-up with a work-around using string literals so we are not dependent on a new GCC to come. The workaround has performance very close to the Emacs modified for my patched GCC I've experimented with.

On my dev machine I native compile all Emacs in ~60min total CPU time (to be divided on multiple cores). That means I have it ready in ~6min! Considering the number of bootstraps I do for development I'm very satisfied about that to say the least.

As a reference the full bootstraps of the branch without native compilation takes about on the same machine ~25min total CPU time. This implies that deferred-compilation is now not anymore a mandatory to have mitigation but a nice compelling to automatically compile packages.

Also memory consumption during compilation benefits from that. Now is possible to compile on 32bit systems all Emacs at speed 2 and native compilation should be much more accessible for constrained systems.

Given now anonymous lambdas are compiled I've invested some time optimizing the middle end to take advantage of that and took some simple measures.

There are few interesting point specific to lambda compilation.

The original lambdas definition is kept through the whole pipeline of the compiler so they can be executed in the compile time if necessary, eventually the native compiled version replace it only in the generated code.

Being lambdas objects they are transparently propagated within the SSA lattice. This implies that in forms like the following

(let((f (lambda(x)
(1+ x))))
...
(funcall f y))

the compiler is able to prove that the first argument offuncall is the lambda defined above. The native compiler will then remove the call tofuncalland rewrite it as a direct call to the compiled lambda.

Given lambdas are 'immediate objects' that don't have to go through name resolution as conventional functions this optimization is always safe to be performed and does not have to be gated at speed 3.

funcallremoval, as we have seen in the past, can be very beneficial for performance but also enable GCC for inlining the lambda if convenient.

Also worth noting that the above snippet is about whatcl-flet and other macros expand in, so hopefully this work benefits them all. Compiling the whole Emacs I'm counting 17744 lexical scoped lambdas now compiled.

To measure the effect of these modification I've added three u-benchmarks toelisp-benchmarks.They leverage local functions usingcl-flet,pcaseand closures.

I compared the results of the currentfeature/native-compwith 9daffe9cfefrom about 4 weeks ago with no lambda support.

Most of tests are not affected includingmap-closure.Closures are still not native compiled and more work will be required for that.

fletis about 50% faster and alsopcaseshows some measurable improvement.

The patches for the Windows support has been merged, also Nico has upstreamed the support on thelibgccjitside, thanks!

I ported and tested the branch onX86_32for bothwide-intand nonwide-intconfiguration. This implies that the back-end can now generate code with the tag bits in MSB or LSB position according to the configuration. Still I managed to boot only with NATIVE_FAST_BOOTor atcomp-speed0 due to the 2GB addressable memory limit that we still violate (SeeOptimizing the build).

A mechanism for lazy loading the function documentation from the .elnfiles is now in place. This allow for reducing the number of unnecessary objects that the Garbage Collector has to traverse.

Reworking the code generation for 32bit I've measured a reduction of the compilation time of ~15%.

Following that I received anexcelent reportfrom Kévin Le Gouguec on memory consumption and compile-time analyzing the compilation process.

As follow-up on that now theleim/sub-folder is by default not compiled. Being these files data and not code it should not affect performance.

The overall compile time is then reduced respect to the original one by a factor two. I can now build on my compile-box a full Emacs atspeed2 in ~47min, this to be compared with the original ~100min on the same machine for the branch at the state ofUpdate 7.

The maximum memory used for the build (single threadspeed2) now peaks around 3GB while compilingOrgand as a consequence is still out of the addressable limit for 32bit systems. This will be a subject of optimization for the future.

Is now possible to selectively exclude files from being native compiled by deferred compilation using comp-deferred-compilation-black-list.

Similarly but for bootstrapcomp-bootstrap-black-listhas been added.

This is really the big boy that kept me busy for the last almost 3 weeks.

Now the native compiler is finally compiling also anonymous lambdas.

Before pushing the branch I tested it at my best, I hope there are no regressions. Also I still have to complete the tuning of the compiler to fully take advantage of that but this is a major improvement.

I'd like to come back on this with a post to discuss it better because it should have measurable performance implications.

The number of parallel compilation threads used by native-compile-asyncis now controlled by the comp-async-jobs-numbercustomize.

This uses by default half of the available CPUs (or at least one) or can be tuned manually.

Is possible to change dynamically this while compiling and have the system converging to the desired value.

Whencomp-deferred-compilationis non nil and a lexically bound .elcdefining functions is loaded then an asyncronous native compilation is queued for it. When this is finished function definitions in the compilation unit are automagically swapped for the native one.

This works similarly to an asyncronous jit compiler but still retains the advantage of being able to save to disk. Simply reloading the compiled output at the next startup saves from unnecessaries recompilations.

This is mechanism is general and works very well for handling transparently package compilations.

Starting from the observation that native compiling all Emacs can be overkill and takes a long time I've added to the build system the possibility to native compile exclusively the compilation unit used for producing the dumped Emacs image. All other lisp files in this case are byte-compiled conventionally.

It can be used as follow:

make NATIVE_FAST_BOOT=1

The compile time for a bootstrap at speed 2 in this case goes down one magnitude order from ~1000m to ~100m CPU time (to be divided by the machine parallelism used).

The produced Emacs if used withcomp-deferred-compilationenabled will then native compile only the used files while having the system immediately already usable. Essentially Emacs will asynchronously compile and load itself while already running.

In case you want to try this remember that Emacs will compile the file being loaded only whencomp-deferred-compilationis non nil, so make sure this is set very early into your.emacs.

On the Emacs CI for every push we now test for bootstrap the stock configuraiton and the native compiled one at speed 0 1 2 (1 appears to be broken). Thanks Michael for suggesting this and explaining how to configure it.

Received the first patch!! Thanks Adam.

Somebody apparently had it running on Windows 10 hacking libgccjit! (Chinese):

http:// albertzhou.net/blog/2020/01/emacs-native-comp.html

OSX apparently works but only speed 0 for now:

https://gist.github /mikroskeem/0a5c909c1880408adf732ceba6d3f9ab

I believe next is more debugging and start thinking aboutmake install.

A better allocation strategy for relocated objects is now in place. This should benefit memory usage and (as a consequence) GC time.

Now different Emacs configurations and/or architectures can build on the same Lisp code base.

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

As example a file.../foo.elwill 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.

The same idea applies to all compilations meaning main build process as packages when gets built.

Optimize qualities (read compilation flags) are now stored in every elnfile. Is now possible to inspect them as:

(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))>

I've made a docker image for people intrested in trying this branch out without having to compile and/or install Emacs and libgccjit.

https://hub.docker /r/andreacorallo/emacs-nativecomp

I'll try to keep it updated. Also I plan to setup a small CI to test that the latest GCC does not break with our build.

The variables layout in the generated code has been redesigned. Now every call by reference gets its own unique array to be used by the arguments. This should generate slightly better code limiting spilling.

Doese not impact on compilation time, but produced binaries (as expected) are slightly smaller.

After some interesting bug fi xing is now 2 weeks that a colleague and me are using for everyday production a native compiled Emacs boostrapped atspeed2. So far we have seen no crashes.

I consider havingspeed2 stable a verymajorachievement.

As a consequence with the today push I'm settingspeed2 as default. This brings up compilation time to ~7h CPU time on my laptop (to be divided by the number of CPUs) for a boostrap starting from a clean repository.

I'll look in the future how to mitigate that but is important to test with optimizations engaged.

Also a pass to performself Tail Call Optimizationhas been added. This is for now active only atspeed3.

Traditionally Emacs Lisp does not perform TCO. This pass should give more support to the programmer if a functional programming style is adopted.

Compilation is invoked with:

(native-compile-async"/path/to/test.el")

In this case the following compilation parameters has been used:

• comp-speed2
• comp-debug1
• comp-verbose3

Note: all the dumped data-structures presented below have been collected from the*Native-compile-Log*buffer that was created because of thecomp-verbosevalue.

The compilation goes through the following passes:

To load the compilation unit:

(load "test.eln" )

Floadhas been modified and will callFnative_elisp_loadif a .elnfile is found. This will callload_comp_unit.

load_comp_unitwilldynlib_symlooking for the following symbols into our.elnfile to perform with them the following actions:

• Callfreloc_hash(function returning a string to sign freloc_link_table) and check its content. Fail in case it does not match.
• Setcurrent_thread_reloc(static pointer holding the address of current_thread).
• Setpure_reloc(static pointer holding the address ofpure).
• Setfreloc_link_table(static pointer to a structure of function pointers in use to call from native compiled functions into Emacs primitives).
• Calltext_data_reloc(function returning a string) andread the vector of Lisp objects used by native compiled function. In this case:

[0 nil bar message "i is: %d" foo 1 "F666f6f_foo" "

(fn X)" t consp listp]

• Setd_reloc(static array of Lisp objects in use by compiled functions).

After thistop_level_runis called. Here's its pseudo source:

externunioncomp_Lisp_Object
top_level_run(unioncomp_Lisp_Objectpar_0)
{
unioncomp_Lisp_Object[1] local;
unioncomp_Lisp_Objectlocal0;
structcomp_handler*c;
unioncast_unionunion_cast_29;
unioncast_unionunion_cast_30;
unioncast_unionunion_cast_31;

entry:
/*Top level*/
local0 = par_0;
/*const lisp obj: foo*/
/*1*/
union_cast_29.v_p = (void*)0x6;
/*1*/
union_cast_30.v_p = (void*)0x6;
/*const lisp obj: "F666f6f_foo"*/
/*const lisp obj: "

(fn X) "*/
/*const lisp obj: nil*/
union_cast_31.v_p = (void*)NULL;
/*calling subr: comp--register-subr*/
(void)freloc_link_table->R636f6d702d2d72656769737465722d73756272_comp__register_subr (d_reloc[(longlong)5], union_cast_29.lisp_obj, union_cast_30.lisp_obj, d_reloc[(longlong)7], d_reloc[(longlong)8], union_cast_31.lisp_obj, local0);
/*const lisp obj: t*/
returnd_reloc[(longlong)9];
}

top_level_runwill perform all the expected modifications to the enviroment by the load of the.elnfile.

In this case it is just calling back into Emacs Fcomp__register_subr(comp.c:3294) asking to register a subr named foo(no other top level forms were present).

Since thenfoois defined assubr,called and treated as that.

Primitive subrs and subrs from native compiled code are distinguishable using the predicatesubr-native-elisp-p (data.c:870).

Here downloadable the full output of the pseudo C-codetest.c

Going in the direction of having to load manyelnfiles I thought it was good to have just one single function link table. This structure is the array of function pointers used by the native compiled code to call Emacs C primitives and functions supporting the run-time.

In the first proposed prototype this structure was defined and compiled differently for everyelnfile. This means that everyeln had his own version of it including just and only the needed pointers.

If this is an advantage in terms of memory usage and locality for loading fewelnit does not scale up very well. It also pulls in a circular dependency on the compiler withadvice.elthat is now removed and, generally speaking, the mechanism is quite simplified.

To produce a single function link table I needed a list of all defined subrs.defsubrhas been modified to cons the list with that. This list is then used both by the compiler and by the load mechanism. It survives bootstrap and restarts in general being dumped as a conventional lisp structure.

The last missing caveat of this is hashing and verifying at load time that theelnfile being loaded is complaint with the running system. This is to be done.

The expected behavior for this to have theelnfile unloaded automatically when this is not in use anymore. This is achieved with the introduction of a new kind of object thenative compilation unit.

The mechanism is quite simple. Every native lisp function has a reference to the original compilation unit. When this is not reachable anymore (because all functions defined into it got redefined) it is unloaded with adlclose(or equivalent) while the object is garbage collected.

This gave me quite some thinking. I guess some story telling will explain some of the rationale that lead to the current implementation. The two main options on the table were:

1. Linker approach.

   Generating code with something that is essentially a C tool-chain using the system linker would have appeared as the first option.

   Still was unclear to me how to cope with side effects that are not barely function definitions. I guess some modification in the actual code-base would have been necessary.

   Also making something future proof for subsequent dumps of the Lisp image looked quite challenging.

2. Including compiled functions into the image dump.

   Including single functions into the dump image had its difficulties too. Essentially I came to the conclusion that trying to break in functions an already compiled and linked shared library, store and then reload functions would translate into: having to parse the elf, re-implement part of the loader, make assumptions on the implementation etc… In short searching for troubles.

In my mind I formed the opinion that breaking the compilation unit in pieces was a mistake and I just had to cope with that. I then came up with the plan of storing eachfullelnfile into the image dump.

This could workbutthe issue is that loading a shared library that resides into memory and not in a file came up not being completely trivial.

dlopentakes a filename as a parameter and I guess (I could be wrong) the secret reason for that is that the dynamic linker is just a program… and yes! In Unix programs work on files…

I then found aboutmemfd_createas possible work-around. This a syscall present in recent Linux kernel that let you create a file descriptor from a piece of your user space memory without having to do any real file copy or real file-system access. The file will appear in some/procsub-folder.

I wasn't very keen on this option because of it being non portable but it looked like the last option and some alternative equivalent tomemfd_createseemed to exists for other non Linux kernels.

I was already half way into the implementation when I stepped back and wanted to rethink to the problem as a whole.

Why the Emacs dump image mechanism was created?

Startup timeis the motivation for that.

The fact that the result is a single file (or two in case of the portable dumper) is, I think, just a (nice) side effect.

Having a single file to load is faster mainly because objects in it are serialized in a binary format and don't need to go through the reader (as it is the case forelcfiles).

But thinking about functions intoelnfiles are already serialized being compiled into machine code and the action of callingdlsymis just doing a lookup asking for the entry point address into memory.

So what's the motivation of dumping if we have alreadyelnfiles? Couldn't we just load them?

No. This would be sub optimal because still in theelnfile format there is a piece of data left that goes through the reader during its load. These are the objects used by functions. We are talking about a vector that is the per compilation unit aggregation of the originalconstant vectors.And last but not least is absolutely nice to have a system where all the enviroment state is dump-able.

Given all these constraints and thoughts my final solution is:

• store into thecompilation unitLisp object (already defined for the gc support) a reference to theelnfile originally loaded.
• at dump-time just dump thecompilation unitobject but donot include theelnfile content in the dump file.
• atcompilation unitload time (during relocation to use precise pdump nomenclature) revive it with a dlopen on the originaleln.
• after all compilation units have been relocated proceed with native functions relocating all function pointer doingdlsym into the compilation unit.

The good side effect of this mechanism is that the data vector does not have to be read by the reader because is naturally dumped and restored by the pdumper infrastructure.

Am I cheating then? Maybe, but I think this solution is quite sound. Nevertheless in case having a unique file is an hard requirement falling back to anmemfd_createlike solution would be just an incremental step on the implemented mechanism.

Here again is missing a sanity check to ensure theelnfile being reloaded has not been changed. To be done.

The standard bootstrap process is not radically changed. Essentially whereelcwere compiledelnfiles are compiled too. Note that the reason whyelccompilation is still necessary is because the native compiler does not support dynamic scope.

When the native compiler fails because of this, Emacs will have the elcfile at disposal for load. A cleaner solution would be to distinguish between dynamic and lexical scoped files while defining compilation targets but… good for now.

I've taken few measures of time regarding the full bootstrap process from a clean repository (including C compilation) on my dual core laptop.

I've leftspeed0 as default for now.

I tried to perform some measurement on startup time using:

time ~/emacs/build/src/emacs -batch

But on my system the difference looks within the noise level and the startup time for both is ~0.1s.

Similar result trying to measure the difference of time needed to (require 'org).

I've added an initial support to thedisassemblefunction for native compiled code. This iswhat it looks likedisassembling on my machinebubble-no-consfromelisp-benchmarks.

Note some pseudo C code and comments are intermixed with the assembly byobjdump.This is because the function was compiled usingcomp-debug1 therefore some debug symbols are emitted to ease the compiler debug.

gccemacsis not a jitter. The compilation output (.elnfiles) are elf files suitable for being reloaded between different sessions.

I believe this solution has advantages over the jitter approach not having the duty to recompile at every start-up the same code.

This is a key advantage especially for an application sensitive to the start-up time as Emacs is. Moreover more time can be spent for advanced compile time optimizations.

Some complication to have the system re-loadable exists but is worth paying.

A further advantage of this solution is the potential for reducing load-time. Optimizing for load time should be further investigated.

Plugging into the gcc infrastructure is done throughlibgccjit.

Despite what the name suggestlibgccjitis usable not just for making jitters but for any other kind of compiler.

libgccjitcan be seen as a way to drive the gcc in form of shared library using function calls. In other words this is probably the 'cheapest' way to write what is technically named a front-end in compiler jargon.

While I'm writing I recall few (I think good) reasons why I decided to replicate some optimizing compiler algorithmics outside gcc:

• The gcc infrastructure has no knowledge that a call to a primitive (sayFcons) will return an object with certain tag bits set (in this case say is a cons). The only feasible way to inform it would be to use LTO but I've some doubts this would be practical for this application.
• I decided to layout the activation frame with an array to hold lisp objects local to the function. This not to have to move and store these whenever a call by ref is emitted. To avoid having the compiler clobber all the local objects in the activation frame every time one of these function calls is emitted, I decided to lift the objects that are not involved by this kind of calls in the equivalent of conventional automatic local variables. To do this I need to propagate the ref property within the control flow graph.
• Gcc infrastructure has no knowledge of what lisp pure functions are therefore this is a barrier for its propagation.
• Gcc does not provide help for bo xing and unbo xing values.
• The propagation engine can be used for giving warnings and errors at compile time.

gccemacscompilation process can be divided into 3 main phases:

• byte-compilation

  This is the conventional Emacs byte compilation phase, is needed because the output of the byte compiler is used as input for the following phase.

• middle-end

  Here the code goes through different transformations. This is implemented intolisp/emacs-lisp/comp.el

• back-end

  This defines inliner and helper functions and driveslibgccjit for the final code generation. It is implemented in src/comp.c.

Having realized it was quite easy to feed the propagation engine with additional information I've implemented two entry points.

These are:

• comp-hint-fixnum
• comp-hint-cons

As an example this is to promise that the result of the following expression evaluates to a cons:

(comp-hint-cons x)

Propagation engine will use this information to propagate for all the m-vars influenced by the evaluation result of(comp-hint-cons x)in the control flow graph.

Atcomp-speedsmaller then 3 the compiler hints will translate into assertions verifying the property declared.

These low level primitives could be used to implement something like the CLthe.

This section applies to the (few) functions exposed to the gcc, namely:car,cdr,setcar,setcdr,1+,1-,- (Fnegate).

Atcomp-speed3 type checks will not be emitted if the propagation has proved the type to be the expected one for the called function.

The native compiler can be debugged in several ways but I think the most propaedeutic one is to setcomp-debugto 1. In this way the compiler will depose a.cfile aside the.eln.

This is not a true compilable C file but something sufficiently close to understand what's going on. Also debug symbols are emitted into the.elntherefore is possible to trap or step into it using gdb.

Note thatcomp-debugset to 1 has a negative impact on compile time.

In order to have something to optimize for and measure we have put together a small collection of elisp (nano and non) benchmarks.

https://gitlab /koral/elisp-benchmarks

The choice of the benchmarks and their weight is certainly very arbitrary but still… better than nothing.

All benchmarks can be considered u-benchmarks exceptnbodyand dhrystone.Worth nothing that these last two has not been tuned specifically for the native compiler.

On the machine I'm running (i7-6600U) the latest performance figure I've got is the following:

Column explanation:

• byte-codebenchmark running byte compiled (baseline).
• native-benchbenchmark running native compiled on a non native compiled emacs.
• native-allbenchmark running with the benchmark itself and all emacs lisp native compiled.

All benchmarks has been compiled withcomp-speed3 while the Emacs lisp for thenative-allcolumn withcomp-speed2.

Here follows averypreliminary and incomplete performance discussion:

bubblebubble-no-consfibnu-benchmarks shows fair results with no specific tuning.

Recursive benchmarks (suffixed with-recor-tc) shows an enormous uplifts most likely dominated by much faster calling convention. Note that no TCO here is performed.

inclist-no-type-hintsandinclist-type-hintsshows a considerable performance uplift just due to type checks being optimized out thanks to the information coming from the type hints.

nbodyis ~4.6x faster with no lisp specific optimization triggered. This benchmark calls only primitives (as all previous u-benchs) therefore having all Emacs native compiled does not gives any advantage. Probably intra compilation unit call optimization plays a role into the result.

On the other sidedhrystonebenefits quite a lot from the full Emacs compilation having to funcall intostore-substringand string>.

Hope this indicates a potential for considerable performance benefits.

A number of tests is defined incomp-tests.el.This is including a number of micro tests (some of these inherited by Tom Tromey's jitter) plus a classical bootstrap test were the compiler compiles itself two times and the binary is compared.

A couple of colleagues and me are running in productiongccemacs with all the Emacs lexically scoped lisp compiled plus all the elpa folder for each of our setups.

While I'm writing this I've loaded on this instance 18682 native compiled elisp functions loaded from 669.elnfiles.

So far this seems stable.

The following limitations are not due to design limitations but just the state of a "work in progress":

• Only lexically scoped code is compiled.
• Interactive functions are included into eln files but as byte-compiled.(Update 1)
• No doc string support for native compiled functions.(Update 1)
• Limited lisp implementation exposure: Just few function are defined and exposed to gcc:car,cdr,setcar,setcdr, 1+,1-,-(Fnegate). This functions can be fully in-lined and optimized.

• Type propagation:

  Very few functions have a return type declared to the compiler (seecomp-known-ret-types). Moreover type propagation can't relay on the CL equivalent ofsub-type-p.

• Garbage collection support has to be done:(Update 2)

  Once a.elnfile is loaded it is never unloaded even if the subrs there defined are redefined.

• No integration with the build system:(Update 2)

  No native compilation is automatically triggered by the build process.

• Native compiler is not re-entrant:

  Just top level functions are native compiled, the others (lambda included) are still kept as byte-code.

• Better lisp exposure

  As mentioned in the previous paragraph the lisp machinery exposed to the gcc infrastructure is at this point quite limited and should be improved.

• Unbo xing

  Introducing the unbo xing mechanism was considered out of scope for this investigation but is certainly possible to extend the current infrastructure to have it. Unbo xing would have a big impact on performance. Combined with compiler hints should be possible to generate efficient code closing some more gap with C (in some cases probably all).

• Further improving load time performance using the portable dumper for object de/serialization within elns (currently the print read mechanism is in use).
• Provide better compile time warning and errors relying on the propagation engine?
• The real final goal would be to be able to assemble the Emacs image having the native compiled functions replacing all the byte-compiled one out of the box.EDIT:See (Update 2)!

All of this is very experimental. Take it (at your risk) as what it is, a proof of concept.

Feedback is very welcome.