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

Sriraman Tallam via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 24 09:46:13 PST 2020


tmsriram marked an inline comment as done.
tmsriram added inline comments.


================
Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1111
+      this->getFunctionLinkage(GD) == llvm::GlobalValue::InternalLinkage) {
+    std::string UniqueSuffix = getUniqueModuleId(&getModule(), true);
+    if (!UniqueSuffix.empty()) {
----------------
MaskRay wrote:
> `std::string llvm::getUniqueModuleId(Module *M) {`
> 
> What is the second parameter?
> 
> What is the rationale that InternalLinkage is picked here?
This change to LLVM, https://reviews.llvm.org/D73310, contains the modifications to getUniqueModuleId to use the Module Identifier also in the hash.  We found that when "-z muldefs" are used or when there are no globals defined in a module, a unique hash could not be generated.  Using the full module name allows for a unique identifier in these cases.  The second parameter basically allows use of module name and we did not force this  to keep the existing usage as it is.

Internal Linkage is picked because there could be multiple functions of the same name with internal linkage in the final binary.  So, associating sampled profile symbols to the right function name becomes a problem.  Further, if multiple functions of the same name are hot, their profiles are aggregated affecting the optimization itself.  So, a unique name for internal linkage functions will clearly disambiguate the profile information.





CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307





More information about the cfe-commits mailing list