Jan Hubicka <hubi...@ucw.cz> 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 https://golang.org/ref/spec#Import_declarations 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. Ian
