Re: Suppressing native compilation (short and long term)

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

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 issue is when
the advised function is somehow called by the compiler while compiling it's
own trampoline.  Since the call may come from the advised version of some
function used by the compiler, it's difficult to limit the risk without
controlling both the dump and the startup/configuration files.

Lynn

[-- Attachment #2: Type: text/html, Size: 2961 bytes --]