This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: TYPE_BINFO and canonical types at LTO
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc at gcc dot gnu dot org, jason at redhat dot com
- Date: Mon, 17 Feb 2014 21:55:42 +0100
- Subject: Re: TYPE_BINFO and canonical types at LTO
- Authentication-results: sourceware.org; auth=none
- References: <20140214004827 dot GA30858 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1402140937310 dot 1593 at zhemvz dot fhfr dot qr> <20140214165219 dot GA3380 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1402151058590 dot 1593 at zhemvz dot fhfr dot qr> <20140216235524 dot GA27760 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1402171220500 dot 1593 at zhemvz dot fhfr dot qr>
>
> Yeah, ok. But we treat those types (B and C) TBAA equivalent because
> structurally they are the same ;) Luckily C has a "proper" field
> for its base (proper means that offset and size are correct as well
> as the type). It indeed has DECL_ARTIFICIAL set and yes, we treat
> those as "real" fields when doing the structural comparison.
Yep, the difference is that depending if C or D win, we will end up walking the
BINFO or not. So we should not depend on the BINFo walk for correctness.
>
> More interesting is of course when we can re-use tail-padding in
> one but not the other (works as expected - not merged).
Yep.
>
> struct A { A (); short x; bool a;};
> struct C:A { bool b; };
> struct B {struct A a; bool b;};
> struct C *p2;
> struct B *p1;
> int
> t()
> {
> p1->a.a = 2;
> return p2->a;
> }
>
> > Yes, zero sized classes are those having no fields (but other stuff,
> > type decls, bases etc.)
>
> Yeah, but TBAA obviously doesn't care about type decls and bases.
So I guess the conclussion is that the BINFO walk in alias.c is pointless?
Concerning the merging details and LTO aliasing, I think for 4.10 we should
make C++ to compute mangled names of types (i.e. call DECL_ASSEMBLER_NAME on
the associated type_decl + explicitly mark that type is driven by ODR) and then
we can do merging driven by ODR rule.
Non-ODR types born from other frontends will then need to be made to alias all
the ODR variants that can be done by storing them into the current canonical type hash.
(I wonder if we want to support cross language aliasing for non-POD?)
I also think we want explicit representation of types known to be local to compilation
unit - anonymous namespaces in C/C++, types defined within function bodies in C and
god knows what in Ada/Fortran/Java.
Honza
>
> Richard.