[PATCH] D147740: [llvm-profdata] Refactoring Sample Profile Reader to increase FDO build speed using MD5 as key to Sample Profile map

[William Junda Huang via Phabricator via llvm-commits]

huangjd added a comment.

Explaining the behavior of MD5-key FunctionSampleMap

Previously the map is  {SampleContext : FunctionSamples}, where FunctionSamples holds a copy of the SampleContext (but not always enforced, for example when the map is an intermediate product of a merge, or during IPO passes). Currently the map is {Hash(SampleContext) : FunctionSamples}, where FunctionSamples holds the SampleContext immediately after insertion (otherwise the context is lost forever)

When inserting to the map, the caller must provide a SampleContext, so that when an existing entry with the same hash value is found, its SampleContext is compared with the caller's new SampleContext.

If they are the same, then it's actually a match, so the existing FunctionSamples is returned and no insertion happens.

If they are different, then there's a MD5 collision, and in this case, we have to decide which FunctionSamples to keep. The decision is to use the new FunctionSamples and erase the old one, because IPO calls SampleProfileReader:;getOrCreateSamplesFor(), and we want to return a sample with the requested function name, rather than a sample with a *different* function name/SampleContext. In this case since a new entry is inserted with a new FunctionSamples provided by the caller, return.second should be true to indicate a new value is inserted, so that the caller can perform other necessary logic as if a new entry is inserted.

There's not much we can do to keep both entries in case of a collision, as it is very rare (and probably only happens theoretically), and using a multi-map slows down too much.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147740