This is an archive of the discontinued LLVM Phabricator instance.

[PGO] Fix incorrect function entry count
ClosedPublic

Authored by xur on Jul 22 2020, 7:03 PM.

Details

Summary

Function entry count might be zero after the profile counts
reset and before reentry to the function.

Zero profile entry count is very bad as the profile count from BFI
will be wrong.

A simple fix is to set the profile entry count to 1 if there are
non-zero profile counts in this function.

Diff Detail

Event Timeline

xur created this revision.Jul 22 2020, 7:03 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 22 2020, 7:03 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
davidxl added inline comments.Jul 23 2020, 9:02 AM
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
1144

add comment here about the root cause: counter cleared before dump.

If counter promotion is disabled, in what situation entry count can not be recovered with propagation?

xur marked an inline comment as done.Jul 23 2020, 9:30 AM
xur added inline comments.
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
1144

This is independent of count promotion. Usually the entry count is not promoted (unless it's inlined to a callsite inside a loop).

This code here is for the case when we instrument the entry BB. If the entry BB is instrumented, it cannot be computed from propagation. (MST does not have the redundancy to recover)

Typically, it happens this way: for a func with a long running loop, after we reset the counter, the entry counters of this func are also zeroed out. If we dump the counters in the middle of the loop, the entry count will still be 0.

If we promote the counters inside the loop, the counter value inside the loop will be 0 (because the updates are in the exit block -- never exercised). If we disable the promote, the counter value insides the loop are OK.

davidxl added inline comments.Jul 23 2020, 9:53 AM
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
1144

ok. what if entry is not instrumented, but two post-dom successors? If they are zeroed out, is there a way to recover?

davidxl added inline comments.Jul 23 2020, 10:25 AM
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
1144

Also look at the caller of this function -- even when AllZeros is true, this function is still called, so the entry count may be wrongly fixed up.

1345

Just this fix should be enough to fix the insanity, right?

xur marked 3 inline comments as done.Jul 23 2020, 4:49 PM
xur added inline comments.
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
1144

It will not fix here, but later. When we set the entry count.

1144

When AllZeros is set, the entry count we set here is NOOP.

The caller (annotateAllFunctions) has a shortcut when AllZero is 0. It sets call setEntryCount directly (to 0) and skip counter population.

Maybe I should return early here if AllZero is 0.

1345

This only fixes the entry for the func. It will not contribute to the count value population.

davidxl added inline comments.Jul 23 2020, 4:55 PM
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
1144

Skipping allzero sounds good.

1345

ok

xur marked an inline comment as done.Jul 23 2020, 4:57 PM
xur added inline comments.
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
1144

I think the reason I did not return early here was to detect the error when there was inconsistent number of counters.

davidxl accepted this revision.Jul 24 2020, 9:49 AM

lgtm

This revision is now accepted and ready to land.Jul 24 2020, 9:49 AM
This revision was automatically updated to reflect the committed changes.