This is an archive of the discontinued LLVM Phabricator instance.

[AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360)
ClosedPublic

Authored by xbolva00 on Jan 22 2022, 12:44 PM.

Details

Summary

Problem: Migration to new PM broke flatten attribute.

This is one use case why LLVM should support inlining call-site with alwaysinline. The flatten attribute is nowdays broken, so we should either land patch like this one or remove everything related to flatten attribute from Clang.

Second use case is something like "per call site inlining intrinsics" to control inlining even more; mentioned in
https://lists.llvm.org/pipermail/cfe-dev/2018-September/059232.html

Fixes https://github.com/llvm/llvm-project/issues/53360

Diff Detail

Event Timeline

xbolva00 created this revision.Jan 22 2022, 12:44 PM
xbolva00 requested review of this revision.Jan 22 2022, 12:44 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJan 22 2022, 12:44 PM
xbolva00 edited the summary of this revision. (Show Details)Jan 22 2022, 12:44 PM
xbolva00 added inline comments.Jan 22 2022, 12:47 PM
llvm/lib/Transforms/IPO/AlwaysInliner.cpp
98

avoid DCE of internal functions without always_inline; check test pr2945 in always-inline.ll

ormris removed a subscriber: ormris.Jan 24 2022, 11:52 AM

Aiming this fix for LLVM 14.0.

The existing implementation only inlines top level call sites, which doesn't match gcc where all calls are recursively inlined [1]. gcc's implementation makes more sense IMO, only inlining top level call sites doesn't seem super useful.

I'd vote for properly implementing [1] or removing our support for flatten.

[1] https://lists.llvm.org/pipermail/llvm-dev/2019-November/136514.html

xbolva00 added a comment.EditedJan 25 2022, 10:09 AM

There is also second use case which I mentioned and I am interested in.

I'd vote for properly implementing [1] or removing our support for flatten.

I would rather prefer to restore atleast something which was working before new PM and then improve it, instead of full user unfriendly removal thanks to oversight during new PM transition.

Imagine also possible use case with those intrinsics:

...
__builtin_flatten(foo());
...

sounds good for the purposes of going back to what we had before, but we should reconsider the attribute support

llvm/lib/Transforms/IPO/AlwaysInliner.cpp
98

no need to change in this patch, but it looks like that was a past limitation, removing any dead internal function should be fine (subject to comdats). either we should not delete any function or we should attempt to remove any function we can

llvm/test/Transforms/Inline/always-inline.ll
147

s/CHECK-CALL/CHECK/g should be good enough? any reason for outer7b? it's exactly the same as outer7a

xbolva00 updated this revision to Diff 402994.Jan 25 2022, 12:11 PM
xbolva00 retitled this revision from [AlwaysInliner] Enable call site inlining to make flatten attribute working again (PR53360) to [AlwaysInliner] Enable call site inlining to make flatten attribute working again (#53360).

Thanks, addressed review comments.

we should reconsider the attribute support

I agree.

xbolva00 updated this revision to Diff 402997.Jan 25 2022, 12:17 PM
xbolva00 added inline comments.
llvm/lib/Transforms/IPO/AlwaysInliner.cpp
98

Thanks for info, changed to delete them.

llvm/test/Transforms/Inline/always-inline.ll
147

Yes, simplified.

aeubanks accepted this revision.Jan 25 2022, 1:04 PM
aeubanks added inline comments.
llvm/test/Transforms/Coroutines/coro-retcon-once-private.ll
6

CHECK-NOT: define {{.*}} @f is probably a bit more robust

This revision is now accepted and ready to land.Jan 25 2022, 1:04 PM
This revision was landed with ongoing or failed builds.Jan 25 2022, 1:56 PM
This revision was automatically updated to reflect the committed changes.

Yeah, possible as inliner removes internal unused functions (small change before commit, missed check-clang).

I will revert and fix.