This adds a detailed profile summary in llvm-profdata. The summary is in the form of one or more triples of the form (P, N, M) which is interpreted as if we look at the Top-N counts in the profile, their sum accounts for P percentage of the sum of all counts in the program and the minimum count in the Top-N is M.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
tools/llvm-profdata/llvm-profdata.cpp | ||
---|---|---|
59 ↗ | (On Diff #44353) | Add simple summary data such as MaxFunctionCount and MaxBlockCount here. |
63 ↗ | (On Diff #44353) | Make this a private method. Instead add a public method: addCount(const InstrProfRecord &) |
63 ↗ | (On Diff #44353) | AddCount --> addCount |
82 ↗ | (On Diff #44353) | Make this vector a member of the ProfileSummary class. The use model (and in the future by InstrProfWriter ) should be like this: ProfileSummary PS; for each InstrProfRecord R: PS.addCount(R); PS.computeProfileSummary(cutoffs); vector<..>& sums = PS.getProfSummary(..); |
83 ↗ | (On Diff #44353) | getProfileSummary |
83 ↗ | (On Diff #44353) | Use a scaled up integer to represent percentage. Talk to Cong about introducing a common interface for that (similar to BranchProbability) |
91 ↗ | (On Diff #44353) | use a different name for the local variable (conflict with member variable) |
360 ↗ | (On Diff #44353) | This should be moved to ProfileSummary |
362 ↗ | (On Diff #44353) | PS.addCount(Func); |
364 ↗ | (On Diff #44353) | Remove this |
Thanks eraman! Comments inline --
tools/llvm-profdata/llvm-profdata.cpp | ||
---|---|---|
45 ↗ | (On Diff #44353) | Nit: I have a hard time parsing this comment. Wdyt of omitting this paragraph and opting for shorter comments on the fields instead? I suggest; float Cutoff; //< The execution count percentile, [0, 100]. uint64_t MinExecuteCount; //< Minimum execution count for this percentile. uint64_t NumBlocks; //< Number of blocks in this percentile. Or something along those lines, I don't think my wording there is perfect :). |
74 ↗ | (On Diff #44353) | I believe this entire conditional can be safely replaced with ++CountFrequencies[Count];. |
109 ↗ | (On Diff #44353) | You can avoid this construct by inverting the order of your loops, i.e iterate over the cutoffs then the histogram entries. Briefly; PSE NextEntry; for (float Cutoff : Cutoffs) NextEntry.Cutoff = Cutoff; std::tie(NextEntry.MinExecuteCount, NextEntry.NumBlocks) = AccumulateCountsTo(Cutoff); |
Addressed reviewers' comments
tools/llvm-profdata/llvm-profdata.cpp | ||
---|---|---|
45 ↗ | (On Diff #44353) | I agree that the comments I have leave much to be desired, but I am not sure the comments on the fields, in isolation, give a clear picture on what is being done. |
82 ↗ | (On Diff #44353) | My problem with this approach is what this allows doing PS.computeProfileSummary(cutoffs1); PS.getProfSummary(); If you want to separate compute and get calls, I prefer passing the cutoffs in the constructor, provide a public get method which returns cached results if available and calls compute method if no cached data is available. This is what I have done now. |
83 ↗ | (On Diff #44353) | cl::opt<float> is used in a few places, so this is not new. I don't do much FP computation here. Letting the user pass a scaled up percentage value as an integer seems inconvenient to me (especially documenting how to use it). Alternatively, I can get the floats, scale it to an integer value and then use integer arithmetic elsewhere. Thoughts? |
109 ↗ | (On Diff #44353) | I don't see a good way of doing this without passing an iterator of the CountFrequencies map to the Accumulate method. Do you prefer that over the current implementation? |
tools/llvm-profdata/llvm-profdata.cpp | ||
---|---|---|
82 ↗ | (On Diff #44577) | This is reasonable -- the benefit of allowing computing summary of different cutoffs with the same PS is minimal. |
83 ↗ | (On Diff #44577) | so -- for option part, using float is fine. What I am concerned is PorgramSummaryEntry has a float member. Eventually, I will need to write those entries to Indexed Profile header, so an integer representation there is better. |
109 ↗ | (On Diff #44577) | current accumuated count can be passed to the Accumator methods. I think vsk's suggestion makes the code slightly more readable. |
tools/llvm-profdata/llvm-profdata.cpp | ||
---|---|---|
45 ↗ | (On Diff #44577) | Fair enough. Maybe comments on the fields could help trim down the long-form comment? |
109 ↗ | (On Diff #44577) | You could use a lambda to capture the map iterator, or go with David's suggestion. I imagine both would be clean. I'm mostly concerned about avoiding the 'double-break' pattern, and would prefer less direct manipulation of iterator objects. |
Address review comments.
tools/llvm-profdata/llvm-profdata.cpp | ||
---|---|---|
83 ↗ | (On Diff #44577) | Ok, I've changed even the options to use ints. Main issue is whether the help message makes it clear what the numbers mean. |
tools/llvm-profdata/llvm-profdata.cpp | ||
---|---|---|
45 ↗ | (On Diff #44670) | Let me know if this looks better. |
test/tools/llvm-profdata/general.proftext | ||
---|---|---|
66 ↗ | (On Diff #44670) | The default cutoffs only have 3 percentiles, how come the dump shows more? |
78 ↗ | (On Diff #44670) | Add a test with more than one explicit cutoffs? |
tools/llvm-profdata/llvm-profdata.cpp | ||
132 ↗ | (On Diff #44670) | Return vector<..>&. |
488 ↗ | (On Diff #44670) | the scale is defined to be 1000000 |
LTGM (after making getDetailedSummary() method return reference).
What is the plan to add similar support for Sample FDO?
I had addressed it in my last revision.
What is the plan to add similar support for Sample FDO?
I assume we want to treat line numbers as blocks for this purpose. I'll work on it.