Re: Suppressing native compilation (short and long term)

[Andrea Corallo]

Lynn Winebarger <owinebar@gmail.com> writes:

> On Sat, Oct 15, 2022, 10:29 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>  > From: Lynn Winebarger <owinebar@gmail.com>
>  > Date: Sat, 15 Oct 2022 10:10:23 -0400
>  > Cc: Eli Zaretskii <eliz@gnu.org>, Andrea Corallo <akrl@sdf.org>, Lars 
> Ingebrigtsen <larsi@gnus.org>, 
>  >       liliana.prikler@gmail.com, rlb@defaultvalue.org, 
>  >       emacs-devel <emacs-devel@gnu.org>
>  > 
>  > Didn't you, a couple of years ago, suggest generating generic trampolines 
> (per function signature), compile
>  > those with gccjit, then just use them as needed rather than compiling 
> separate trampolines for every subr?
>  > Presumably the system would still occasionally need to compile a 
> trampoline for a new signature, but the
>  > generic trampoline would not be named so it couldn't cause an infinite 
> recursion by being advised before
>  > being compiled.
>
>  If we want to compile all the trampolines AOT, that is already
>  possible in Emacs 29, one just needs to actually do it when building
>  Emacs.
>
> The question was about whether trampolines could be designed in such a way as 
> to avoid invoking a separate compiler
> process without requiring architecture-dependent binary hacking on templates.
> I believe I was recalling one of Stefan M's suggestions for just this problem 
> from a couple of years ago.  
> Also, my understanding from this conversation is that trampolines may be 
> required at run-time that aren't known at
> build-time.

The list of primitives is known at build time, so is the list of
possibly needed trampolines.

  Andrea