This is an archive of the discontinued LLVM Phabricator instance.

[mlgo] Incrementally update FunctionPropertiesInfo during inlining
ClosedPublic

Authored by mtrofin on May 17 2022, 3:49 PM.

Details

Summary

Re-computing FunctionPropertiesInfo after each inlining may be very time
consuming: in certain cases, e.g. large caller with lots of callsites,
and when the overall IR doesn't increase (thus not tripping a size bloat
threshold).

This patch addresses this by incrementally updating
FunctionPropertiesInfo.

Diff Detail

Event Timeline

mtrofin created this revision.May 17 2022, 3:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 17 2022, 3:49 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
mtrofin requested review of this revision.May 17 2022, 3:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 17 2022, 3:49 PM
kazu added inline comments.May 25 2022, 9:13 AM
llvm/include/llvm/Analysis/FunctionPropertiesAnalysis.h
118

Could we rename this variable to CallSiteBB or something? I got confused on a statement like &Entry != &*Caller.begin() below.

121

Is this variable dead? If so, please remove it.

llvm/include/llvm/Analysis/MLInlineAdvisor.h
74

May I suggest an empty line between a function definition and a member variable declaration?

llvm/lib/Analysis/FunctionPropertiesAnalysis.cpp
15

Are we using this? If not, please remove it.

46

May I suggest an empty line here between the two function definitions?

65–84

Could we use sizeWithoutDebug instead?

TotalInstructionCount += Direction * BB.sizeWithoutDebug();
83

Could we use !pred_empty(&BB)?

That said, the original code does not check whether the predecessor list is empty or not, but your version does. Does that matter?

158

Could we have some comment?

// Update the properties of those basic blocks that are likely modified or copied from the callee.
165–166
for (const BasicBlock *Succ : successors(BB))
  Worklist.push_back(Succ);
169

Should we hide this assert under EXPENSIVE_CHECKS or something? IIUC, FunctionPropertiesInfo::getFunctionPropertiesInfo visits all of the caller's basic blocks, so we might trigger a quadratic behavior when the caller has many call sites.

That said, this check may be much lighter than, say, the BFS traversal of the callee in InlineCost.cpp, so I am not sure how much we should worry about this.

llvm/lib/Analysis/MLInlineAdvisor.cpp
387

I am not sure how significant this is, but the constructor for FPU may visit a few basic blocks (and possibly some memory allocations). It would be nice if we could avoid invoking this constructor when Recommendation is false.

437

This comment is related to my comment on MLInlineAdvice::MLInlineAdvice above. If we are not modifying the IR here at all, the code would look clearer without this assignment statement.

That said, we can remove this line if and only if we avoid calling the constructor FPU for Recommendation == false cases.

If we turn FPU into llvm::optional, then we might consider:

assert(!FPU.hasValue())

to ensure that we don't subtract things and walk away without adding things back.

By the way, we still have to stick to llvm::optional because std::optional is in C++ 17, which is beyond LLVM Coding Standards allows at the moment.

mtrofin updated this revision to Diff 432123.May 25 2022, 1:57 PM
mtrofin marked 12 inline comments as done.

feedback

llvm/lib/Analysis/FunctionPropertiesAnalysis.cpp
83

yes - it's an in-flight fix-up. Post-inlining, esp. in the case of invoke inlining, former landing pad BBs may become dead. They are still visible if one indiscriminately goes over the list of BBs of the function. But they are dead, so might as well not account them.

169

When this check is enabled, the source of the problem this patch fixes would be re-surfaced. We only hit that in a very few cases, so while we want it fixed, it's normally relatively light (like you said). Also, we already have builds with assertions enabled (but not EXPENSIVE_CHECKS), so these 2 reasons together make asserts more attractive (readily check-able with no (much) impact)

kazu accepted this revision.May 25 2022, 2:17 PM

LGTM. Thank you so much for updating your patch!

This revision is now accepted and ready to land.May 25 2022, 2:17 PM
This revision was landed with ongoing or failed builds.May 31 2022, 5:27 PM
This revision was automatically updated to reflect the committed changes.