> On Thu, 11 Sep 2014, Jan Hubicka wrote: > > > Hi, > > this patch adds computation and streaming of mangled type names. As > > suggested by Jason, > > it simple calls DECL_ASSEMBLER_NAME on all names types and lets C++ supply > > them. > > This makes it possible to stablish precise ODR type equivalency at LTO > > (till now we can > > do that only for complete class types with virtual methods attached to > > them). > > Lto type merging is then updated to register all types into the ODR type > > hash. This > > makes warnings to be output for ODR violations. Here are ones output for > > Firefox: > > http://kam.mff.cuni.cz/~hubicka/odr-warnings-firefox.txt > > > > As discussed earlier, in addition to ODR warnings that seems useful, I would > > like to use it for TBAA analysis for ODR types that are not structurally > > equivalent to non-ODR types, so C++ programs will get better alias analysis > > and > > for other tricks, such as more agresively merging ODR types. > > > > I believe this makes sense (is orthogonal) with early debug info (for > > warnings, TBAA > > and devirtualization). It can be also used to more agresively merge debug > > information > > as done by LLVM. > > > > The change increase LTO object fules by about 2% (uncompressed by 6%) and > > also > > increase WPA memory use and streaming times by about same percentage. It is > > not small and thus I made it optional (enabled by default for now). We > > could see > > how benefits relate to this cost once the other three parts are implemented. > > > > Bootstrapped/regtested x86_64-linux, seems sane? > > It looks sane, but when early debug is completed we likely will drop > all the elaborated types from decls. Thus to keep the ODR type you'd > have to keep (and compute early as well) their DECL_ASSEMBLER_NAME?
I currently compute it in free_lang_data. Obviously we can compute earlier (in the frontend) as fit. > > Can't we just store a hash of the assembler name? From alias analysis > perspective false aliasing due to a hash collision is harmless, no? > Maybe not for ODR warnings though. At least a hash would be way > cheaper than those usually very large strings.... Hmm, interesting idea. False positives are harmless for alias analysis, they do matter for type inheritance graph construction but if we decide we will ever care only about polymorphic types, we can always use the virtual table name to resolve conflicts. We will get false ODR violation warnings, but the chances would be very low. > > You probably want to restrict ODR types to aggregates? For ODR warnings and TBAA I think i want other types, too. But yep, we need to handle gracefuly component types that does not have names and we could drop names of types and handle them as component types as it seems fit. OK, so if you agree, I will go ahead with this patch and we can resolve these details incrementally. Honza > > Richard.
