This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Using One Definition Rule for types during LTO devirtualizatoin?
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Jason Merrill <jason at redhat dot com>, gcc-patches at gcc dot gnu dot org, mjambor at suse dot de
- Date: Mon, 17 Jun 2013 16:25:49 +0200 (CEST)
- Subject: Re: [RFC] Using One Definition Rule for types during LTO devirtualizatoin?
- References: <20130617100510 dot GB3276 at kam dot mff dot cuni dot cz> <51BF088F dot 4010406 at redhat dot com> <20130617130737 dot GF2605 at atrey dot karlin dot mff dot cuni dot cz> <51BF0FE7 dot 5020807 at redhat dot com> <20130617133511 dot GA13003 at kam dot mff dot cuni dot cz> <51BF1475 dot 4020603 at redhat dot com> <20130617141851 dot GC13003 at kam dot mff dot cuni dot cz>
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,
so given C++ manually implemented in C you cannot expect same
"vtable" contents when the types have the same name.
Richard.