[CSSPGO] Do not use getCanonicalFnName in pseudo probe descriptor decoding

[hoy]

Summary

Pseudo probe descriptors are created very early in the pipeline where function names just come from the front end and are not yet decorated. So calling getCanonicalFnName on the function names in probe desc is basically a no-op, which also addes a depenency from MC to ProfileData unnessesarily.

[hoy]

Rebasing

[wlei]

LGTM, thanks!

[wenlei]

llvm/lib/MC/MCPseudoProbe.cpp

360

does this have __uniq.? Can we assert it does not contain .?

[hoy]

llvm/lib/MC/MCPseudoProbe.cpp

360

It can have that since the uniq suffx is from the frontend. We can assert it doesn't have .llvm etc...

[wenlei]

lgtm, thanks.

llvm/lib/MC/MCPseudoProbe.cpp

360

ok, as long as it's verified to be no-op now, the risk of something breaking this is low. I think it's fine to leave it as is too.

[stella.stamenova]

This change introduced a race condition in the build and we saw it fail in our private buildbots on both Ubuntu and Windows because of a dependency on Attributes.inc (the target intrinsics_gen) which had previously been covered by the ProfileData library. I haven't confirmed whether https://reviews.llvm.org/rG68d6c3e4486c6743dfa419ec0d919d8e97fdad05 removed that dependency by removing the header from ProfileData, though it likely does, so I wanted to leave a note here for anyone else who runs into this - or if it recurs.

[hoy]

In D107838#2939694, @stella.stamenova wrote:

This change introduced a race condition in the build and we saw it fail in our private buildbots on both Ubuntu and Windows because of a dependency on Attributes.inc (the target intrinsics_gen) which had previously been covered by the ProfileData library. I haven't confirmed whether https://reviews.llvm.org/rG68d6c3e4486c6743dfa419ec0d919d8e97fdad05 removed that dependency by removing the header from ProfileData, though it likely does, so I wanted to leave a note here for anyone else who runs into this - or if it recurs.

Thanks for letting me know. As you pointed out, https://reviews.llvm.org/rG68d6c3e4486c6743dfa419ec0d919d8e97fdad05 should fix the issue.

llvm/lib/MC/CMakeLists.txt

add_llvm_component_library(LLVMMC
 
   ADDITIONAL_HEADER_DIRS
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/MC
 
   LINK_COMPONENTS
   Support
   BinaryFormat
   DebugInfoCodeView
-  ProfileData
   )
 
 add_subdirectory(MCParser)
 add_subdirectory(MCDisassembler)

llvm/lib/MC/MCPseudoProbe.cpp

while (Data < End) {
     uint32_t NameSize = std::move(*ErrorOrNameSize);
 
     auto ErrorOrName = readString(NameSize);
     if (!ErrorOrName)
       return false;
 
     uint64_t GUID = std::move(*ErrorOrGUID);
     uint64_t Hash = std::move(*ErrorOrHash);
-    StringRef Name =
-        FunctionSamples::getCanonicalFnName(std::move(*ErrorOrName));
+    StringRef Name = std::move(*ErrorOrName);
 
     // Initialize PseudoProbeFuncDesc and populate it into GUID2FuncDescMap
     GUID2FuncDescMap.emplace(GUID, MCPseudoProbeFuncDesc(GUID, Hash, Name));
   }
   assert(Data == End && "Have unprocessed data in pseudo_probe_desc section");
   return true;
 }