sepavloff added a comment. In https://reviews.llvm.org/D40567#940025, @rsmith wrote:
> What actual problem is this solving? These IR type names exist only for the > convenience of humans reading the IR, and making them long (potentially > extremely long) by including template arguments seems likely to hinder that > more than it helps. There is a case when IR type names are essential. If `llvm-link` sees opaque type in one TU, it tries to merge it with its definition in another TU. The type name is used to identify proper definition. All template specializations share the same name, so `llvm-link` has to choose random type, which results in incorrect IR. Such IR prevents from some whole-program analyses. This problem cannot be solved by `llvm-link`, as some information is already lost. Possible IR bloating due to long type names is indeed an issue. https://reviews.llvm.org/D40508 tries to solve it by replacing long type name or part of it by SHA1 hash. Type names become shorter and still are usable for type identification across different TUs. Template arguments are added to the type names only if compilation produces IR (including embedded IR in LTO), machine code generation is not affected. If adding template arguments in all cases is not appropriate, probably it makes sense to have an option, something like '--precise-ir', that would turn this generation on? It could be used in the cases when accurate type information in IR is required. https://reviews.llvm.org/D40567 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
