> On 10 Dec 2024, at 16:20, Arsen Arsenović <ar...@aarsen.me> wrote:
> 
> Trimmed sending this email by accident.  Reposting the latter section:
> 
> WRT the question of Clang compatibility: the layout of the frame is
> changed when internal padding is present (i.e. when the promise type has
> an alignment greater than 2 * sizeof(void*)), the padding used to be
> present between the resume/destroy pointers and promise:
> 
>  struct frame_type {
>    void (*resume)(frame_type*);
>    void (*destroy)(frame_type*);
>    /* padding of size PN */
>    promise_type promise;
>  }
> 
> ... whereas now the frame_type looks like:
> 
>  struct frame_type {
>    char _Coro_padding[PN];
>    void (*resume)(void*);   // actually takes &frame->resume
>    void (*destroy)(void*);  // actually takes &frame->resume
>    promise_type promise;
>  }
> 
> This is significant because a __builtin_coroutine_promise now operates
> differently, it no longer needs to account for the promise type padding
> (which is known, FWIW, because it can be determined based on the
> template argument to coroutine_handle, and it is UB to pass incorrect
> one) in order to go from a "resume pointer" (which previously coincided
> with the frame types' "this") to the promise pointer.  This is both an
> ABI and (builtin) API break.
> 
> WRT resuming the coroutine, I _think_ resuming still works across
> compilers, because the handling of this change is inside the
> resumer/destroyer, so the actual function resuming still only needs to
> do:
> 
>  _1 = this->_M_fr_ptr; // actually the "resumer pointer" now
>  _2 = MEM[(void (*<T123>) (void *) *)_1];
>  _2 (_1);
> 
> ... but I have not tried.  Regardless, with __builtin_coro_promise
> differences, it is hard to imagine a case in which compatibility is
> certain.
> 
> I can hold off on this change until Itanium is notified about it, and/or
> LLVM developers decide to implement it also.

I think it is useful to fix the under-aligned frames (using the existing
ABI for the builtin and the placement of the padding).  That brings
actual immediate benefit.

It islikely that the process of deciding if the combined set of ‘vendors’
still want to adopt the ‘padding before’ change will take some time.
(and I’d not be surprised if the end decision was to stick with what we
have for Itanium).

Iain


> 
> Have a lovely day.
> -- 
> Arsen Arsenović

Reply via email to