Re: [PATCH] core: Support heap-based trampolines

[Richard Biener <richard.guenther@gmail.com>]

On Sun, Jul 16, 2023 at 12:39 PM FX Coudert via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Hi,
>
> This is a reworked version (following review) of the patch by Maxim Blinov and Iain Sandoe enabling heap-based trampolines. What has changed since the last version:
>
> - wording changes, preferring to use “heap-based trampolines” rather than “off-stack trampolines”
> - the option triggering generation of these new trampolines is now a binary choice: -ftrampoline-impl=[stack|heap]
> - some adjustments due to changes in the macOS build flags in GCC since last year
>
> Regarding testing, this patch has had excellent exposure on darwin (both x86_64 and aarch64) because it was part of Iain’s branch, distributed by many macOS distros/vendors (including Homebrew) for more than a year, and there was no bug report against the feature or implementation. On x86_64-linux, I have regression-tested it in three different configurations:
> - a default build
> - a build with --enable-heap-trampolines
> - a build with --enable-heap-trampolines and heap trampolines forced by default (forcing HEAP_TRAMPOLINES_INIT = 1)
>
> There are no regressions in any of these settings (apart from an expected missing warning in gcc.dg/Wtrampolines.c).
>
> ----------
>
> From the original review, one question asked (by Jeff Law) was: whether the two linux implementations should be dropped, and the configure time
> selectability as well. Regardless of the answer to the first question, I think we probably want to retain the later, even if only for darwin, as we want to implement this only on recent darwin versions.

Since this affects the ABI of libgcc I think we don't want that part
to be user configurable but rather determined by
some static list of targets that opt-in to this config.

You mention setjmp/longjmp - on darwin and other platforms requiring
non-stack based trampolines
does the system runtime provide means to deal with this issue like an
alternate allocation method
or a way to register cleanup?

Was there ever an attempt to provide a "generic" trampoline driven by
a more complex descriptor?
(well, it could be a bytecode interpreter and the trampoline being
bytecode on the stack?!)

Otherwise I suggest to split the patch into libgcc, generic and target parts.

Thanks,
Richard.

>
> OK to commit?
>
> FX
>
>