This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Improve TBAA for types in anonymous namespaces

Jan Hubicka <> writes:

>> >> 
>> >> OK.  I wonder if we can/should carve off some bits to note
>> >> type_with_linkage_p and type_in_anonymous_namespace_p in the tree
>> >> itself?  At least in type_common there's plenty of bits left.
>> >> Not sure how expensive / reliable (non-C++?) those tests otherwise are.
>> >
>> > It also makes me wonder if other languages (D, Ada, go, Fortran...) have
>> > concept of anonymous namespace types - that is types that are never
>> > interoperable with types from another translation unit.  That would
>> > justify the extra flag pretty well.
>> >
>> > Similarly for types with name mangling defined.  Both these bits can be
>> > made indpendent of C++.
>> Go has the concept, but it implements it by mangling the names with the
>> package-path, which is required to be unique within an application (the
>> package-path is normally the path used to find an import, so it is
>> inherently unique within a file system).
> Currently we implement ODR names only for C++.  If Go has similar
> concept (i.e. types has mangled names and equal names implies equal
> types acros sunits), we may want to implemnt it too and improve TBAA for
> go programs..  I wonder is there something I can read about go types and
> mangling?

I don't know that the mangling is documented anywhere.  It's just an
implementation detail.  The basic idea follows from which explains how to
refer to identifiers defined in other packages.  There is no requirement
that the identifiers in different packages have unique names.  That is
if packages p1 and p2 both define a type T, then p1.T and p2.T are
different types.

Within the GCC middle-end, names will have the mangling applied, so if
the middle-end sees two types both named p1.T, then they are indeed the
same type.  It may be possible to use this fact for better TBAA when
using LTO.

> This would be good motivation to make ODR type machinery indepenent of
> C++.  Until now it was only used to drive devirtualization (which needs
> BINFOs that are not done by go FE either) and produce ODR violation
> warnings (that I am not sure if would make sense for go), but with TBAA
> I think I can take a look into this.

ODR violations can't arise in Go, since there is no way to give two
distinct types/variables/functions the same mangled name.

Go could in principle benefit from devirtualization optimizations, but
they would look pretty different than they do in C++ and I doubt they
could actually share an implementation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]