This change refactors the ProfileKind enum into a bitset enum to
represent the different attributes a profile can have. This change
simplifies the logic in the instrprof writer when multiple profiles are
merged together. In the future we plan on introducing a new memory
profile section which will extend the enum by one additional entry.
Without this change when accounting for memory profiles will have to be
maintained separately and will make the logic more complex.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Cleanup for review -
- Added some more descriptive comments.
- Removed a couple of unintentional blank lines.
- Removed a couple of commented lines of code.
llvm/include/llvm/ProfileData/InstrProfReader.h | ||
---|---|---|
93 | It seems like these helper methods could still be defined using the new bitset, which would reduce some of the code churn? |
llvm/include/llvm/ProfileData/InstrProfReader.h | ||
---|---|---|
93 | My rationale for removing the helpers was
I agree retaining the helpers reduces code churn and I've made the changes to keep them. PTAL, thanks! |
lgtm
llvm/include/llvm/ProfileData/InstrProfWriter.h | ||
---|---|---|
48 | Was the InstrEntryBBEnabled parameter just never used? I didn't see any changes to callsites. |
@xur Could you please take a look with a focus on ensuring that this change retains the semantics that you expect? Previously there were different enum values which indicated CS+IR vs IR only. Now the IR bit is set for both cases (to be consistent with the version mask). I believe this was the original intent. The only change I had to make was reorder the print in the text format writer.
llvm/include/llvm/ProfileData/InstrProfWriter.h | ||
---|---|---|
48 | I didn't find any uses in llvm and I don't see it being used in the original commit: https://git.io/JDt8k. There is a chance that it could be used by a downstream user but it's unlikely? I'll wait for @xur to chime in. |
llvm/include/llvm/ProfileData/InstrProf.h | ||
---|---|---|
281–282 | Yes this makes the enum composable and brings it in line with the Variant mask encoding in the indexed profile header. Let me go ahead and submit this (after rebasing and testing) so that you can rebase your changes. Thanks for the heads up! |
llvm/include/llvm/ProfileData/InstrProf.h | ||
---|---|---|
284–287 | Can we expand these names instead of using acronyms? It would help us remember what these flags do by being more descriptive. Example: InstrProfKind::BB => InstrProfKind::WithFunctionEntry |
llvm/include/llvm/ProfileData/InstrProfReader.h | ||
---|---|---|
447 | Since these were in a header but spread across different inherited classes of the same base I moved these to the .cpp and refactored it into a common static function in https://reviews.llvm.org/D118656. Thanks! | |
llvm/lib/ProfileData/InstrProfWriter.cpp | ||
336 | I'm not sure it will help much but I'll take a look in the patch to rename the enum types to more descriptive names. |
I've been working on a new coverage instrumentation in D116180 that I guess would need to be added this this enum. The plan was to first add function entry coverage, then basic block coverage.