On Mon, Jun 24, 2019 at 11:57 AM Jan Hubicka <hubi...@ucw.cz> wrote:
>
> Hi,
> thanks for comitting the patch!
> > > > 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.
>
> I think because Richard defined gimple memory model this way after fair
> amount of frustration from placement news, stack slot sharing issues
> and non-conforming codebases :)
>
> I think for normal user variables this is overly conservative.
> At the moment TBAA is bit of a mess. Once it is cleaned up, we could
> see if restricting this more pays back and then we would need to
> find way to pass the info to middle-end (as it does not
> know difference between aligned_storage and other stuff).
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.
> Note that devirtualization machinery is bit more agressive than TBAA
> model I am currently aiming for (for example assuming that user variable
> of given type are not placement new replaced), but I think here we are
> relatively safe because we do so only for non-POD types where
> construction/destruction ought to be paired.
Agreed.
> > > 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.
>
> 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?
> > > 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.
>
> My patchset considers all C++ types inter-operating with non-C++ types.
> So first we load all types and do the following:
>
> During streaming I populate ODR type hash with ODR types and canonical
> type hash with types not originating from C++.
>
> Once all types are in memory I do following:
> 1) For every structure/union with linkage
> - see if there is structurally equivalent non-C++ type in canonical
> type hash (where structural equivalence is defined in very
> generous way ignoring pointer types, type tags and field names so
> interoperability with fortran is safe)
>
> if there is no matching type and no detected ODR violation declare
> mark the type to be handled by ODR name in step 2
> 2) for every structure/union originating from C++ compute the canonical
> type by canonical type hash query. If in 1) we decided that given
> ODR type is unique the canonical type hash compare type by name
> rather than by structure.
> I do not handle enums since those conflicts with integer that is
> declared in every translation unit.
>
> 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.
Jason
