[RFC] Using One Definition Rule for types during LTO devirtualizatoin?
Jan Hubicka
hubicka@ucw.cz
Mon Jun 17 14:33:00 GMT 2013
> On Mon, 17 Jun 2013, Jan Hubicka wrote:
>
> > > On 06/17/2013 09:35 AM, Jan Hubicka wrote:
> > > >To get meaningful warnings, we need to know what decls/types are subject
> > > >to ODR. Do you think you can make C++ FE to drop a flag so middle-end know?
> > > >We can LTO ODR and non-ODR languages together.
> > >
> > > Basically everything in C++ is subject to the ODR. There are two
> > > cases: either there can be only one definition anywhere (e.g. normal
> > > variables and functions, anything local to such a function) or all
> > > definitions need to be identical.
> >
> > Does ODR hold also for extern "C" declarations in C++?
> >
> > >
> > > In C, you can treat all structurally identical types as the same, right?
> >
> > Sort of. Currently we have two notions of equivalency of types
> >
> > 1) TYPE_CANONICAL that is strictly merged by structural equivalence.
> > The equivalency is defined by gimple_canonical_types_compatible_p
> > and is very conservative (i.e. ignores type names for example)
> >
> > This is what drives most of backend and aliasing machinery.
> >
> > Having false equivalences leads to worse TBAA, false nonequivalences
> > leads to wrong code due to aliasing.
>
> That's 100% accurate.
>
> > 2) Richard's type (and now tree) merging. This merging is conservative
> > on what is considered to be equivalent type and compare pretty
> > much everything in the in-memory type representaion (i.e. names, modifiers,
> > BINFOs, stuff that matters for debug or devirt machinery)
> >
> > false equivalences leads to loss of debug info quality and false
> > devirtualizations, false nonequivalences leads to explossions of memory
> > use and streaming time for Firefox or any other huge LTO build.
>
> There should not be false equivalencies - false equivalencies can
> lead to random bugs including wrong-code. Basically we consider
> two tree SCCs equivalent if all values inside them are equal and
> the tree SCC is structurally equivalent.
>
> > At least this is my understanding, Richard know more ;)
> >
> > ODR adds third notion of equivalency that should sit strictly in between
> > and in fact perhaps for ODR types we can make 1)=2)=ODR unless ODR is
> > obviously violated.
>
> The question is when will two types be "ODR equivalent" but not
> "tree equivalent". Certainly there is no such thing as "ODR" for C,
yes, that is why I think we need flag specifying if type is ODR or not.
An idea would be to check ODR flagged types of ODR equivalency. If there is a
match, look if CANONICAL_TYPE match. If it does not, we can warn user. If it
does, pick the one that is more specified and make it win (similarly as we have
can_prevail predicate for DECLS I suppose). Perhaps with some extra
equivalency tests + warnings.
Honza
More information about the Gcc-patches
mailing list