On 6/2/25 11:43 AM, Iain Sandoe wrote:
On 2 Jun 2025, at 16:33, Iain Sandoe <i...@sandoe.co.uk> wrote:
Hi Jason
On 2 Jun 2025, at 16:20, Jason Merrill <ja...@redhat.com> wrote:
On 5/31/25 3:19 PM, Iain Sandoe wrote:
Some small cleanups found while working on other changes, tested
on x86_64-darwin, OK for trunk?
thanks
Iain
--- 8< ---
We were incorrectly guarding all the frame cleanups on the
basis of frame_needs_free (which is always set for the present
code-gen since we have no allocation elision). The net result
being that the (incorrect) code was behaving as expected.
We built, but never used, a label for the frame destruction;
in practice it is never triggered independently of the promise
and argument copy destruction.
Would it make sense to call the destructor for the frame type as a whole rather
than the promise and arguments separately?
At present,
- because the standard describes the frame in terms of allocation and
deallocation rules (although we do build a record type for it)
- because the frame copies of local vars need to be constructed and destructed
as needed (i.e. in the same manner as on the stack)
(and especially since we want to “fold” the use of storage as an optimisation
on the TODO (again in the manner of the stack))
there is neither frame constructor nor destructor;
It is specifically the case that the coroutine frame object is *not* a first
class type - much EWG debate in particular with the BGN NB folks.
We reserve the right to modify it in arbitrary ways to optimise - the folding
of the storage is just the first we have an implementation for;
- we could also delete members late in the middle end if they were
determined to be unused.
- we could also do the “HALO” thing and remove the allocation in favour of
stack if the coroutine can be proven not to escape the caller’s context.
So that is not a short-term solution - and possibly non-trivial - thoughts?
Thanks for the detail, never mind then. The patch is OK.
Jason
