Re: [PATCH] c++, coroutines: Stabilize names of promoted slot vars [PR101118].

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

On Tue, Mar 28, 2023 at 1:16 PM Iain Sandoe <iain@sandoe.co.uk> wrote:
>
> Hi Richard
>
> > On 28 Mar 2023, at 12:27, Iain Sandoe <iain@sandoe.co.uk> wrote:
> >> On 28 Mar 2023, at 11:58, Richard Biener <richard.guenther@gmail.com> wrote:
> >>
> >> On Mon, Mar 27, 2023 at 9:32 AM Iain Sandoe <iain@sandoe.co.uk> wrote:
> >>>
> >>>> On 27 Mar 2023, at 12:48, Richard Biener <richard.guenther@gmail.com> wrote:
> >>>>
> >>>> On Mon, Mar 27, 2023 at 8:58 AM Iain Sandoe <iain@sandoe.co.uk> wrote:
>
> >>>>
> >>>> If the two layouts are used to access the same objects you might run
> >>>> into TBAA issues.
> >>>> But making them appear the same but still separate types won't help that issue
> >>>> (but -flto will "fix" it for you then)
> >>>
> >>> … but I wonder if I should be preventing LTO from doing this (perhaps my frame
> >>> type needs a uniquing addition, and then we would not care about the differing).
> >>>
> >>> hmm… now I’m not sure that this patch is the right fix .. I’d welcome Jason’s take
> >>> on this.
>
> taking another look to refresh my memory
>  - the frame type is named for the function that it corresponds to.
>
> from the testcase example:
> e.g. if we have a function _Z3fn1v the frame type will be _Z3fn1v.Frame
> so -  if that is incorrect, then we have deeper problems - since that would imply that the
> orignal function was also incorrectly named.
>
> So, ISTM that LTO is DTRT to merge the types (and presumably the functions) and the
> fix proposed is minimally invasive for this late in the cycle .. with an intent to revisit this
> in the future.

Btw, I agree the fix is a strict improvement even without fully
understanding the context.

So it's OK from my side.

Richard.

> Iain
>