[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Sriraman Tallam via Phabricator via cfe-commits]

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