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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: phillip.lord@russet.org.uk, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> Date: Wed, 10 Feb 2021 20:41:07 +0000
>> 
>> > 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.
>
> That's 20%, not too bad.

Agreed, we could also improve this with some parallelism later on, BTW I
think most people will not build these AOT.

>> > 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.
>
> How many bytes is the trampoline?  With 1500 primitives, we are
> talking perhaps about 20KB bloat?  That's not very significant, IMO.

On my system each trampoline is 45K, this translates in ~65M bloat that
is probably more problematic.  OTOH this should be measured on Windows
as it really depends on the object format I guess.

  Andrea