Current implementation promotes a non-cold function in the SampleFDO profile
into a hot function in the FDO profile. This is too aggressive. This patch
promotes a hot functions in the SampleFDO profile into a hot function, and a
warm function in SampleFDO into a warm function in FDO.
Details
Diff Detail
Event Timeline
llvm/lib/ProfileData/ProfileSummaryBuilder.cpp | ||
---|---|---|
227–228 | Symbolic constants seem reasonable. These values should not be encountered in real profiles. 2^64 is too large for any counter values to come close. There might be other ways to implement -- like extending the profile format. But this is the simplest way. | |
llvm/tools/llvm-profdata/llvm-profdata.cpp | ||
508–515 | We want to set the entry count so that the function will be warm The entry count needs to be greater than ColdThreshold but less than HotThreshold. I think I need to add code to make sure it's less than HotThreshold. |
llvm/lib/ProfileData/ProfileSummaryBuilder.cpp | ||
---|---|---|
227–228 | profile counter reader should do something when reading those values into instrProfRecord so that the special values are not leaked. | |
llvm/tools/llvm-profdata/llvm-profdata.cpp | ||
519 | are the counts all -1 or -2 in this case? what is the point of scaling? |
llvm/lib/ProfileData/ProfileSummaryBuilder.cpp | ||
---|---|---|
227–228 | Agreed. We can have some APIs to InstrProfRecord to encapsulate the values. The other alternative is to extend the profile format to have a information section for each function. Right now we are overload some information in the function hash function. I think have an optional information section for each function would be useful. | |
llvm/tools/llvm-profdata/llvm-profdata.cpp | ||
506 | will fix | |
519 | If we assign -1 or -2, we will not do scaling, it will early return on line 504. This part is doing the scaling on the original counters. |
This patches adds the support for mapping to warm function, just following the existing practice (where it maps to hot functions).
The constant of -1 is already in llvm.
Since we are talking about hiding these values within InstrProfRecord, I would also change the way how the information pass to to down streams: instead of using entry counts,
For a function with InstrProfRecord value of -1, we would set the function attribute hot,
For a function with InstrProfRecord value of -2, we would remove function attribute cold if it has, otherwise do nothing.
For warm functions, we could also delete the function profile in the supplementation step. But it's less optimal:
(1) we will have a no-profile-found warning (it is not a big problem, as the default is off)
(2) we will not be able to fix the incorrect user annotation (where the user sets the function to cold).
This is more complex change that hide the pseudo count values in InstroProfRecord.
Needs to touch more files. But I think this improves the original patch.
llvm/include/llvm/ProfileData/InstrProf.h | ||
---|---|---|
844 | pass CountPseudoKind | |
llvm/lib/ProfileData/InstrProf.cpp | ||
721 | typo: proifiles | |
722 | typo peseudo | |
725 | We should probably assume/require both profiles are (or not) supplemented, and always take the non pseudo one. Or do not support merge with supplemented profile (i.e. only supplement after merging). |
llvm/include/llvm/ProfileData/InstrProf.h | ||
---|---|---|
844 | Ack. | |
llvm/lib/ProfileData/InstrProf.cpp | ||
721 | Ack. | |
722 | Ack. | |
725 | Supplementing can produce a normal profile (only scaling), or a profile with pseudo counts. Probably the fist suggestion is the way to go: give a hard error when merging profile with pseudo counts and without pseudo counts. |
Integrated David's review comment.
For the merge profile merge, also skip the value profile merge if the count is pseudo kind.
Also added some tests to test pseudo profile merge.
pass CountPseudoKind