[llvm] [SampleProfileMatcher] Sample profile duplication to avoid stale CFG profile matching conflicts (PR #202460)

[via llvm-commits]

HighW4y2H3ll wrote:

> Thanks for working on this. I like the approach overall.
> 
> One gap: the conflict detection only sees anchor matches from runStaleProfileMatching, but FuncToProfileNameMap is also populated by matchFunctionsWithoutProfileByBasename() (pre-loop) and by functionMatchesProfile() as a side effect during LCS probing. Claims from those sources never hit the scan.
> 
> So e.g. if F1 is basename-matched to P (never a callee anchor) and F2 later matches P via the call-graph path, the scan only sees F2, records no conflict, and both resolve to P → the assert still fires.

Thanks for the review! This scenario shall be taken care of because 1) `matchFunctionsWithoutProfileByBasename()` guarentees 1:1 mapping between pre-matched IR functions and profile. 2) `functionMatchesProfile()` is ran through the top-down order inside `runStaleProfileMatching` and `FuncToProfileNameMap` is updated incrementally based on the callees. (the nested calling path inside `functionMatchesProfileHelper` won't update `FunctionToProfileNameMap` because `FindMatchedProfileOnly` bypasses that.) So I think checking the callees in `FuncToProfileNameMap` right after the LCS call-graph matching shall be sufficient to avoid duplications?

> 
> Could we instead enforce uniqueness over the whole FuncToProfileNameMap after all claims are made (one normalization pass), so basename and comparator-side-effect claims are covered too?

The problem is that the `IRToProfileLocationMap` is already updated during each stale profile matching iteration, and it will abort in the middle of the iteration. There won't be a good point to do a centralized normalization pass unless we run through the top-down function list twice... but that doesn't feel efficient if we could just detect it onsite..

https://github.com/llvm/llvm-project/pull/202460