This change enables pseudo-probe-based sample counts to be consumed by the sample profile loader under the regular -fprofile-sample-use switch with minimal adjustments to the existing sample file formats. After the counts are imported, a probe helper, aka, a PseudoProbeManager object, is automatically launched to verify the CFG checksum of every function in the current compilation against the corresponding checksum from the profile. Mismatched checksums will cause a function profile to be slipped. A SampleProfileProber pass is scheduled before any of the SampleProfileLoader instances so that the CFG checksums as well as probe mappings are available during the profile loading time. The PseudoProbeManager object is set up right after the profile reading is done. In the future a CFG-based fuzzy matching could be done in PseudoProbeManager.
Samples will be applied only to pseudo probe instructions as well as probed callsites once the checksum verification goes through. Those instructions are processed in the same way that regular instructions would be processed in the line-number-based scenario. In other words, a function is processed in a regular way as if it was reduced to just containing pseudo probes (block probes and callsites).
Adjustment to profile format
A CFG checksum field is being added to the existing AutoFDO profile formats. So far only the text format and the extended binary format are supported. For the text format, a new line like
!CFGChecksum: 12345
is added to the end of the body sample lines. For the extended binary profile format, we introduce a metadata section to store the checksum map from function names to their CFG checksums.
I guess it makes sense to treat missing entry to have zero count instead of unknown because the function profiles with unmatched CFGchecksum has been dropped, is that right?
If it is, can we check CFGchecksum not zero here instead of ProfileIsProbeBased or ProfileIsCS? When CFGchecksum is not zero and matched, we are confident the profile is accurate no matter what kind of profile it is.
Another thing is: I think debug info based profile can have a similar checksum then it can use a similar strategy here as probe based profile. It may not be a CFGchecksum because debug info based profile has no idea about CFG, so it is better to rename CFGchecksum to something more general.