On Tue, Mar 28, 2023 at 1:16 PM Iain Sandoe <i...@sandoe.co.uk> wrote: > > Hi Richard > > > On 28 Mar 2023, at 12:27, Iain Sandoe <i...@sandoe.co.uk> wrote: > >> On 28 Mar 2023, at 11:58, Richard Biener <richard.guent...@gmail.com> > >> wrote: > >> > >> On Mon, Mar 27, 2023 at 9:32 AM Iain Sandoe <i...@sandoe.co.uk> wrote: > >>> > >>>> On 27 Mar 2023, at 12:48, Richard Biener <richard.guent...@gmail.com> > >>>> wrote: > >>>> > >>>> On Mon, Mar 27, 2023 at 8:58 AM Iain Sandoe <i...@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 >
