> On Thu, 18 Jul 2019, Jan Hubicka wrote: > > > Hi, > > this patch adjusts LTO tree merging to treat anonymous namespace types > > as local to a given TU, so just like !TREE_PUBLIC decls they are not > > merged (this is unify_scc change). This makes them to get different > > canonical types and act as independent types for TBAA. > > > > I also modified canonical type calculation to never consider anonymous > > namespace types as interoperable with structurally equivalent types > > declared in non-C++ translation units. > > > > Both these changes are tested by the testcase (first change makes set1 > > and set2 independent and second chnage makes set1&set2 independent of > > set3). > > > > lto-bootstrapped/regtested x86_64-linux > > 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.
I was thinking of that too. The pattern matching is somewhat ugly. It is now sanity checked to non-C++ FEs by verifying that CXX_ODR_P is set if the test matches, so it seems to work reliably (byt indeed there was issues until this stage1) After we dropped -fno-odr-type-merging these predicates are no longer absolutely terrible though. type_with_linkage_p boils down to testing that TYPE_NAME is TYPE_DECL and it has ASSEMBLER_NAME set. Anonymous namespace just looks for <anon> in the type name. I plan to do some profiling and we can see how bad are they these days. Flag would also save the weird set of tests we do in need_assembler_name_p to not get confused by other languages. Honza
