On Mon, Jun 24, 2019 at 7:28 AM Richard Biener <rguent...@suse.de> wrote:
> On Mon, 24 Jun 2019, Jan Hubicka wrote:
>
> > > > This simple (untested) patch doesn't avoid creating the unnecessary
> > > > as-base types, but it should avoid using them in a way that causes
> > > > them to be streamed, and should let them be discarded by GC.
> > > > Thoughts?
> > >
> > > Looks better than Honzas patch fixing a single place.
> >
> > I wonder if we can go ahead with Jason's patch to handle the common
> > case.
>
> I hope so - Jason?
Committed.
> > > I've spent some thoughts on this and I wonder whether we can
> > > re-implement classtype-as-base with fake inheritance (which would
> > > also solve the TBAA alias set issue in a natural way). That is,
> > > we'd lay out structs as-base and make instances of it use a
> > >
> > > class as-instance { as-base b; X pad1; Y pad2; };
> > >
> > > with either explicit padding fields or with implicit ones
> > > (I didn't check how we trick stor-layout to not pad the as-base
> > > type to its natural alignment...).
> > >
> > > I realize that this impacts all code building component-refs ontop
> > > of as-instance typed objects so this might rule out this approach
> > > completely - but maybe that's reasonably well abstracted into common
> > > code so only few places need adjustments.
> >
> > Modulo the empty virtual bases which I have no understnading to I
> > suppose this should work.
> >
> > One issue is that we will need to introduce view_convert_exprs at some
> > times.
> >
> > As
> >
> > class a var;
> > class b:a {} *bptr;
> >
> > var.foo;
> >
> > Expanding this as var.as_base_a.foo would make access path oracle to
> > disambiguate it from bptr->as_base_b->as_base_a.foo which is wrong with
> > gimple memory moel where we allow placement new replacing var by
> > instance of b.
Why do we allow that? I would expect that to only be allowed if a is
something like aligned_storage, i.e. a thin wrapper around a char/byte
buffer.
> Ick. IIRC the as-base types were necessary only for
> copying and clobber operations that may not touch the possibly
> re-used tail-padding.
And temporarily during layout, yes. This is all closely related to PR 22488.
> Btw, I still wonder what the ODR says in the face of language
> inter-operation and what this means here? For C++ I suppose PODs
> are not ODR?
The ODR applies to PODs just like other classes. But the ODR says
nothing about language interoperation, that's all
implementation-defined.
Jason
