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