This is an archive of the discontinued LLVM Phabricator instance.

[CSSPGO] Allow inlining recursive call for preinliner
ClosedPublic

Authored by wenlei on Sep 1 2021, 3:57 PM.

Details

Summary

When preinliner is used for CSSPGO, we try to honor global preinliner decision as much as we can except for uninlinable callees. We rely on InlineCost::Never to prevent us from illegal inlining.

However, it turns out that we use InlineCost::Never for both illeagle inlining and some of the "not-so-beneficial" inlining.

The most common one is recursive inlining, while it can bloat size a lot during CGSCC bottom-up inlining, it's less of a problem when recursive inlining is guided by profile and done in top-down manner.

Ideally it'd be better to have a clear separation between inline legality check vs cost-benefit check, but that requires a bigger change.

This change enables InlineCost computation to allow inlining recursive calls, controlled by InlineParams. In SampleLoader, we now enable recursive inlining for CSSPGO when global preinliner decision is used.

With this change, we saw a few perf improvements on SPEC2017 with CSSPGO and preinliner on: 2% for povray_r, 6% for xalancbmk_s, 3% omnetpp_s, while size is about the same (no noticeable perf change for all other benchmarks)

Diff Detail

Event Timeline

wenlei created this revision.Sep 1 2021, 3:57 PM
wenlei requested review of this revision.Sep 1 2021, 3:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2021, 3:57 PM
wlei added a comment.EditedSep 1 2021, 4:22 PM

Nice to see we can handle recursion inlining. I guess here the recursion inlining is from different call site since we actually do compression to block many "recursion". Now with this, I'm wondering if we can change compression strategy to allow more duplication context, see if we can find a balance between the profile size and duplication.

hoy added inline comments.Sep 2 2021, 8:37 AM
llvm/lib/Transforms/IPO/SampleProfile.cpp
1295

Should this also be enabled for csspgo without preliner?

wenlei added inline comments.Sep 2 2021, 8:52 AM
llvm/lib/Transforms/IPO/SampleProfile.cpp
1295

Hmm.. actually this is what it currently does. UsePreInlinerDecision is on by default for CSSPGO. So basically, we have sample-profile-use-preinliner indirectly controls whether we allow recursive inline. Do you think we should have separate switch just for recursive inlining? That probably makes experimenting with AutoFDO a bit easier too.

hoy added inline comments.Sep 2 2021, 9:15 AM
llvm/lib/Transforms/IPO/SampleProfile.cpp
1295

Oh yeah, UsePreInlinerDecision is on by default for CSSPGO. A separate switch would be more solid like the decision won't be changed when UsePreInlinerDecision is off. It is also handy for experimenting with AutoFDO.

wenlei updated this revision to Diff 370297.Sep 2 2021, 9:24 AM

Address comments.

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

Ok, done.

hoy accepted this revision.Sep 2 2021, 9:48 AM

lgtm

llvm/lib/Analysis/InlineCost.cpp
939

Nit: move this to the field initializer list? AllowRecursiveCall(Params.AllowRecursiveCall.getValue())

This revision is now accepted and ready to land.Sep 2 2021, 9:48 AM
wenlei added inline comments.Sep 2 2021, 9:59 AM
llvm/lib/Analysis/InlineCost.cpp
939

We can't use initializer list directly because that field is in base class (we need it to be in the base because the uses are from base). The params of base's ctor are high level stuff, so I wasn't sure if it's good to add this as a ctor param, and decided to leave it.

hoy added inline comments.Sep 2 2021, 10:00 AM
llvm/lib/Analysis/InlineCost.cpp
939

I see, makes sense to leave it as is.

This revision was automatically updated to reflect the committed changes.