> On 10 Feb 2024, at 17:46, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Sat, Feb 10, 2024 at 05:14:44PM +0000, Iain Sandoe wrote:
>> PR target/113855
>>
>> gcc/ChangeLog:
>>
>> * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
>> available to all sub-targets.
>> * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete.
>> * config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete.
>>
>> libgcc/ChangeLog:
>>
>> * config.host: Add trampoline support to x?86-linux.
>> * config/i386/heap-trampoline.c (trampoline_insns): Provide
>> a variant for IA32.
>> (union ix86_trampoline): Likewise.
>> (__gcc_nested_func_ptr_created): Implement a basic trampoline
>> for IA32.
>
> LGTM.
>
> I bet it probably doesn't work properly for -mx32 (which defines
> __x86_64__), CCing H.J. on that, but that is a preexisting issue
> (and I don't have any experience with it; I guess one would either
> need to add 4 bytes of padding after the func_ptr so that those
> bits remain zeros as sizeof (void *) is 4, but presumably it would be
> better to just use movl (but into %r10) and maybe the jmpl instead
> of movabsq.
It seems that ix86_trampoline_init flips codegen on TARGET_64BIT
so perhaps if we make it __x86_64__ && __LP64__?
I had also considered maybe forcing the alignment of the trampoline
allocations to a cache line (or maybe at least half a cache line).
These considerations are also something to add to the improvements
we can make to generalize the handling.
For now, assuming remaining testing does not throw up any new
issues, I’ll apply this to make progress on the PR.
thanks
Iain
>
> Jakub
>
