Re: [feature/native-comp] breakage on build

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>>         Andrea Corallo via "Emacs
>>  development discussions." <emacs-devel@gnu.org>,
>>         Eli Zaretskii
>>  <eliz@gnu.org>
>> Date: Wed, 10 Feb 2021 08:44:57 +0000
>> 
>> Compiling a trampoline is about 0.2s each (mostly GCC gas ld startup
>> time).  Say we have ~1400 primitives this should translate into ~4.5 min
>> of build time for something that in the average case is largely unused.
>
> 4.5 min out of how much?  Isn't building Emacs with native-comp take a
> long time anyway?

IIRC the full AOT build on my dev machine (8 core 16 threads) is ~19mins.

>> The trouble is that the simple code snippet I posted is not parallel and
>> there's no trivial way to make make aware of all these targets to have
>> it handling the parallelism.
>
> How about if we make the necessary assembly snippet part of the DEFUN
> macro?  Then compiling each .c file will produce those trampolines
> ready to be used, no?  (I admit that I don't really understand the
> details of those trampolines, so maybe the above makes no sense.)

Yes, that would be equivalent for a primitve foo to expand also
something like.

Lisp_Object
Ffoo_trampoline (Lisp_Object arg1, Lisp_Object arg2)
{
  return CALLN (Ffuncall, Qfoo, arg1, arg2);
}

At this point one need also a mechanism set the Ffoo_trampoline address
in our link table when foo is redefined.

One downside of this approach is that the binary is statically bloated
by rarely used code.

  Andrea