This is an archive of the discontinued LLVM Phabricator instance.

[llvm][NFC] Simplify ProfileSummaryInfo state transitions.
ClosedPublic

Authored by mtrofin on May 13 2020, 8:37 PM.

Details

Summary

ProfileSummaryInfo is updated seldom, as result of very specific
triggers. This patch clearly demarcates state updates from read-only uses.
This, arguably, improves readability and maintainability.

Diff Detail

Event Timeline

mtrofin created this revision.May 13 2020, 8:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 13 2020, 8:37 PM

Could you separate all the constification (& possibly/as much of the renaming as possible) from the semantic changes here?

(no need to send the constification for pre-commit review - feel free to commit it before or after the semantic changes depending on what suits/is practical/etc)

llvm/include/llvm/Analysis/ProfileSummaryInfo.h
68

I'd probably write this as Summary != nullptr?

There might be a reason for lazy computation of the summary/thresholds data. +Hiroshi

llvm/include/llvm/Analysis/ProfileSummaryInfo.h
44

may be better to keep this helper for readability.

llvm/lib/Analysis/ProfileSummaryInfo.cpp
103–104

I think the original early return is clearer.

There might be a reason for lazy computation of the summary/thresholds data. +Hiroshi

I'm not sure why.

Could you separate all the constification (& possibly/as much of the renaming as possible) from the semantic changes here?

+1

llvm/include/llvm/Analysis/ProfileSummaryInfo.h
44

+1

64

samples -> summary?

65

refresh() won't read again once once a non-null summary is created.

Do we anticipate a situation where the profile summary in the IR may be set once and then updated later perhaps conditionally? Who should call refresh?

llvm/lib/Transforms/IPO/SampleProfile.cpp
1851

This if statement may suggest that we may not always set it here or may have been set at an earlier point (do we know if that's possible)?

Should we move the refresh call inside the if statement?

mtrofin updated this revision to Diff 264771.May 18 2020, 7:47 PM
mtrofin marked 10 inline comments as done.

feedback

llvm/include/llvm/Analysis/ProfileSummaryInfo.h
65

That's currently the case, too - see the old computeSummary() def and uses.

Re. the second question (if we anticipate a situation...) - my goal with this patch is to help make such analysis simpler, by clarifying where the transitions happen. When such a scenario appears, the agent invalidating the profile should trigger the refresh.

I think, ideally, we'd control the state of the PSI from the pass pipeline through explicit pass calls - it'd make it even more clear what the state is at any given moment. This patch is a step in that direction.

llvm/lib/Analysis/ProfileSummaryInfo.cpp
103–104

We still need to go and compute the thresholds.

llvm/lib/Transforms/IPO/SampleProfile.cpp
1851

That's more clear, indeed.

I still think it'd be best to have the pure formatting changes (clang-format) in a separate patch.

llvm/include/llvm/Analysis/ProfileSummaryInfo.h
65

I think there are two approaches here:

  1. We have a single global point where PSI is filled in. (this might potentially require coordination between different parts of the code.)
  1. We can have multiple points during the pass pipeline where PSI is filled in or updated. (just update PSI as we go and change the metadata.)

Which are we going with?

If 1, would it be useful to make calling refresh again after it's filled into an assert error? Currently it gets dropped silently, but it would catch if someone updates the PS in the IR and tries to update the PSI, but not really updating it.

If 2, would it be useful to make refresh update PSI every time it gets called? (which we could do for 1 as well?)

In D79920#2047502, @yamauchi wrote:

I still think it'd be best to have the pure formatting changes (clang-format) in a separate patch.

I think it's a matter of what scenarios we have: do we have a scenario for ever re-updating the PSI or not.

We do need to work that out, and that's my intention. In the meantime, I believe it would be helpful to simplify the current state of the code. As this patch clarifies state transitions, it should be relatively easy to further simplify it further afterwards.

mtrofin updated this revision to Diff 266260.May 26 2020, 10:11 AM
mtrofin marked an inline comment as done.

removed unrelated clang-format changes

hjyamauchi accepted this revision.May 27 2020, 10:57 AM
This revision is now accepted and ready to land.May 27 2020, 10:57 AM