Use ODR for canonical types construction in LTO

[Jason Merrill]

On Mon, Jun 24, 2019 at 1:46 PM Jan Hubicka <hubicka@ucw.cz> wrote:
> >
> > I thought I remembered someone's recent-ish work to treat specially
> > types containing a char array, but I'm not finding it now.
> >
> > > For dynamically allocated memory as well as for stack space after stack
> > > slot sharing done in cfgexpand I see this is necessary since we do not
> > > preserve any information about placement new.
> >
> > Yes, untyped memory is different, but I'd think that memory allocated
> > through (non-placement) new should also be considered typed.
>
> I will try to return to this once the code is cleaned up. It would
> be quite interesting to make this better defined.
> > >
> > > I think this is what Richard refers to the code generating clobber
> > > statements that is only leaking as-base types to the middle-end visible
> > > part of IL and the code in call.c copying base structures.
> >
> > Right.  Is there a better way we could express copying/clobbering only
> > part of the object without involving the as-base types?
>
> I think currently two variants was discussed
>  1) use the trik Richard proposed for class a containing fake
>     subclass a_as_base that has reduced size (i.e. is the AS_BASE type
>     we have now) and adjust all component_refs accordingly introducing
>     the view_convert_exprs for outer decls.
>
>     Then clobbers and copies in call.c could use the as_base type.

This is the approach I talked about in 22488, which would also fix the
issue of fields with TYPE_SIZE larger than DECL_SIZE.

>  2) expose IS_FAKE_BASE_TYPE to middle-end and teach TBAA machinery
>     about the fact that these are actually same types for everything
>     it cares about.
>
>     We have similar hacks for Fortran commons already, but of couse
>     it is not most pretty (I outlined plan in previous mail)
>
> I would personally lean towards 2 since it will keep all component_refs
> in its current natural form and because I know how to implement it :)
> I guess it is Richi and yours call to pick variant which is better...

Both of these you mention still involve the as-base type.  I was
wondering if there was a way to avoid that.

> > > So at this time basically every C++ type can inter-operate with non-C++.
> > > I was thinking of relaxing this somewhat but wanted to see if C++
> > > standard says something here. Things that may be sensible include:
> > >  1) perhaps non-POD types especially those with vptr pointers do
> > >     not need to be inter-operable.
> >
> > PODs were intended to be the C-compatible subset, yes.
> >
> > >  2) anonymous namespace types
> > >  3) types in namespace
> >
> > As long as these types don't have explicit language linkage (e.g.
> > extern "C"), sure.
>
> Great, I will add those to my TODOs.
> Do we have any way to tell language linkage from middle-end?

Not with a flag, currently, but you could look at the mangled name to
recognize extern "C".

Jason