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. Iain
