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

[Andrea Corallo]

Phillip Lord <phillip.lord@russet.org.uk> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> - With native code you can redefine all of these except for the (very
>>>>   few) primitives we open-code directly in the generated code.  This is
>>>>   a smaller set than the previous one but still not perfect.
>>>
>>> But if we can't build trampolines, currently, the situation is much
>>> worse: many calls to native-compiled Lisp functions from native-compiled 
>>> Lisp
>>> functions can't be advised any more.
>>
>> Correct, but if we can build eln files during the initial compilation we
>> can also build trampolines AOT.  This is just a matter of running:
>>
>> (mapatoms (λ (s)    
>>             (when (subr-primitive-p (symbol-function s))
>>               (comp-trampoline-compile s))))
>>
>> Probably we should wire this in the build system so it's accessible as
>> make target?
>
>
> Why not wire it into the AOT compilation always? Obviously, if it
> doubles the AOT compilation, that might not be such a great idea, but
> otherwise?
>
> Phil

That's a great question.

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.

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.

  Andrea