llvm-project

15faa0ab - [SampleProfileMatcher] Fix direct basename matching for suffixed function names

[SampleProfileMatcher] Fix direct basename matching for suffixed function names Direct basename matching (#184409) silently skips any function whose name carries a suffix, for two reasons: 1. `getDemangledBaseName` demangles the raw name. For names such as `_ZL3fool.__uniq.123`, `_Z3fool.llvm.7`, `.part.N` or `.cfi` the Itanium demangler's root node is a DotSuffix, for which `getFunctionBaseName()` returns null, so the function is never a candidate on either the IR or the profile side. 2. `UpdateWithSalvagedProfiles` keys `FuncNameToProfNameMap` by the raw IR name, but `SampleProfileReader::getSamplesFor(const Function &)` looks it up by `getCanonicalFnName`. A salvaged `.llvm.N` (ThinLTO-promoted), `.part.N` or `.cfi` function therefore still gets no profile. Canonicalize the name before demangling (additionally dropping `.__uniq.N`, which `getCanonicalFnName` keeps when the profile has uniq names), and key the map by the canonical name. Other suffixes such as coroutine `.resume` are kept so those clones do not make a basename ambiguous. The `.__uniq.N` case matters most in practice. The suffix hashes the source path (`-funique-internal-linkage-names`), so moving or renaming a file renames every internal-linkage function in it, and these are exactly the functions basename matching is meant to recover. In CSSPGO profiles from two large production services, `.__uniq.` functions are 17.4% and 8.6% of top-level profiles but carry 39.9% and 29.2% of the samples: internal functions are few, but they are small hot helpers, so their sample density is 2.3x-3.4x that of the average function. Today all of them are excluded from basename matching. Assisted-by: Claude