tmsriram added a comment. In D73307#1942805 <https://reviews.llvm.org/D73307#1942805>, @MaskRay wrote:
> In D73307#1932131 <https://reviews.llvm.org/D73307#1932131>, @rnk wrote: > > > At a higher level, should this just be an IR pass that clang adds into the > > pipeline when the flag is set? It should be safe to rename internal > > functions and give private functions internal linkage. It would be less > > invasive to clang and have better separation of concerns. As written, this > > is based on the source filename on the module, which is accessible from IR. > > The only reason I can think of against this is that the debug info might > > refer to the function linkage name, but maybe that is calculated later > > during codegen. > > > I second this suggestion. `clang/lib/CodeGen/BackendUtil.cpp` > `EmitAssemblyHelper::EmitAssemblyWithNewPassManager` ModulePassManager may be > a more appropriate place for this feature. There are examples from both sides: @rnk getMangledNameImpl for example adds multi-versioning suffixes, "__regcall3_" and "__device_stub". Adding the hash is just so simple. Is a pass really needed? If so, I should parse ".<target>" suffixed Multi-versioining names and insert the hash in between as the demangling looks better? > > > - clang frontend: `#pragma redefine_extname` > - middle end IR->IR: the old pass manager has a feature -frewrite-map-file, > which does a similar thing but is implemented as an IR transformation. ================ Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1060 + const Decl *D = GD.getDecl(); + if (CGM.getCodeGenOpts().UniqueInternalLinkageNames && + !CGM.getModuleNameHash().empty() && ---------------- davidxl wrote: > is the first check redundant now? Good catch, converted to an assert. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73307/new/ https://reviews.llvm.org/D73307 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
