This is an archive of the discontinued LLVM Phabricator instance.

[NFC] [Pipelines] Hoist CoroCleanup as Module Pass (3/5)
ClosedPublic

Authored by ChuanqiXu on Apr 25 2022, 12:33 AM.

Details

Summary

This is similar to previous patch https://reviews.llvm.org/D123925. It could also reduce the time we call declaresCoroCleanupIntrinsics. And it is helpful for further changes.

Diff Detail

Event Timeline

ChuanqiXu created this revision.Apr 25 2022, 12:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 25 2022, 12:33 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
ChuanqiXu requested review of this revision.Apr 25 2022, 12:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 25 2022, 12:33 AM
aeubanks added inline comments.Apr 25 2022, 8:24 AM
llvm/lib/Transforms/Coroutines/CoroCleanup.cpp
57

why are we removing Changed and always invalidating analyses? if we have a module where most functions don't call any of these intrinsics, we're going to unnecessarily invalidate a lot more analyses which will be bad for compile times.

ChuanqiXu added inline comments.Apr 25 2022, 7:01 PM
llvm/lib/Transforms/Coroutines/CoroCleanup.cpp
57

My thought is:
(1) We already checked if there is any coroutine intrinsic in the module before we start the pass.
(2) So there must be some changes for some functions.
(3) So the Changed variable would always be true. So I think it is redundant.

Here is the case that M owns the declaration of some coroutine intrinsics but not a function uses it actually. But I think it wouldn't happen in real cases.

aeubanks accepted this revision.Apr 25 2022, 8:43 PM
aeubanks added inline comments.
llvm/lib/Transforms/Coroutines/CoroCleanup.cpp
57

oh sorry, I forgot this was now a module pass

This revision is now accepted and ready to land.Apr 25 2022, 8:43 PM
This revision was landed with ongoing or failed builds.May 5 2022, 12:19 AM
This revision was automatically updated to reflect the committed changes.