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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
