Am Mittwoch, den 02.10.2019, 15:12 +0200 schrieb Richard Biener:
> On Wed, Oct 2, 2019 at 3:10 PM Richard Biener
> <richard.guent...@gmail.com> wrote:
> >
> > On Wed, Oct 2, 2019 at 2:35 PM Uecker, Martin
> > <martin.uec...@med.uni-goettingen.de> wrote:
> > >
> > > Am Mittwoch, den 02.10.2019, 14:18 +0200 schrieb Richard Biener:
> > > > On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin
> > > > <martin.uec...@med.uni-goettingen.de> wrote:
> > > > >
> > >
> > > Thank you for your answers.
> > >
> > > > > Finally, how does LTO does it? It somehow also needs to unify
> > > > > different tagged types? Could we reuse this mechanism somehow?
> > > >
> > > > LTO structurally merges types via TYPE_CANONICAL. But rules
> > > > for merging depend on language semantics, too much merging
> > > > hinders optimization.
> > >
> > > LTO would need to merge types with identical tag and structure
> > > across TUs anyway as this is needed for C programs to work.
> > > But this implies that it also must merge such types inside a TU
> > > (because merging enforces an equivalence relationship).
> > > So if I am not missing anything important, LTO would already
> > > implement the exact semantics which I propose for C2X.
> >
> > Sure LTO handles C2X fine. The issue is that it creates way
> > larger equivalence classes than necessary for C2X (it has to
> > work across language boundaries where compatibility is much
> > less specified).
Ok, using this would also for our purposes would pessimize things
too much.
> Oh, and LTO does _not_ merge types declared inside a function,
> so
>
> void foo () { struct S { int i; }; }
> void bar () { struct S { int i; }; }
>
> the two S are distinct and objects of that type do not conflict.
This is surprising as these types are compatible across TUs. So
if some pointer is passed between these functions this is
supposed to work.
Best,
Martin
