Hi Michal,
> On 14 May 2023, at 17:31, Michal Jankovič via Gcc-patches
> wrote:
> I do not currently have metrics for this, but I can look into generating
> them,
To be clear, this is not in any way a precondition for patch acceptance
but I am curious as to some idea of the improvements seen.
Hi Iain,
I do not currently have metrics for this, but I can look into generating
them, however I currently do not know of any large open-source projects
using coroutines that I could use for this; I was thinking about using
cppcoro unit tests, but they mostly contain very simple coroutines. I
hav
Hi Michal,
> On 14 May 2023, at 16:36, Michal Jankovič wrote:
>
> Rebased the patch to GCC 14 trunk. Bootstrapped and regression tested
> again on x86_64-pc-linux-gnu, only difference is the new test failing
> without the patch.
(as previously noted, I am much in favour of this optimisation)
D
Rebased the patch to GCC 14 trunk. Bootstrapped and regression tested
again on x86_64-pc-linux-gnu, only difference is the new test failing
without the patch.
On Jul 13 2022, at 2:54 pm, Michal Jankovic
wrote:
> Hi Iain,
>
> thanks for the info. I have some follow-up questions.
>
> On Jul 12
Hi Iain,
thanks for the info. I have some follow-up questions.
On Jul 12 2022, at 7:11 pm, Iain Sandoe wrote:
> Hi Michal,
>
>> On 12 Jul 2022, at 16:14, Michal Jankovič
>> wrote:
>
>> One other related thing I would like to investigate is reducing the
>> number of compiler generated varia
Hi Michal,
> On 12 Jul 2022, at 16:14, Michal Jankovič wrote:
> One other related thing I would like to investigate is reducing the
> number of compiler generated variables in the frame, particularly
> _Coro_destroy_fn and _Coro_self_handle.
>
> As I understand it, _Coro_destroy_fn just sets
Hi Iain,
Thanks for the reply, this is my first time contributing and I am
looking forward to your input.
One other related thing I would like to investigate is reducing the
number of compiler generated variables in the frame, particularly
_Coro_destroy_fn and _Coro_self_handle.
As I understan
Hi Michal,
> On 12 Jul 2022, at 14:35, Michal Jankovič via Gcc-patches
> wrote:
>
> Currently, coroutine frames store all variables of a coroutine separately,
> even if their lifetime does not overlap (they are in distinct scopes). This
> patch implements overlapping distinct variable scopes in
Currently, coroutine frames store all variables of a coroutine separately,
even if their lifetime does not overlap (they are in distinct scopes). This
patch implements overlapping distinct variable scopes in the coroutine frame,
by storing the frame fields in nested unions of structs. This lowers t
