[clang] [llvm] [coro] Lower `llvm.coro.await.suspend.handle` to resume with tail call (PR #89751)
via cfe-commits
cfe-commits at lists.llvm.org
Thu May 2 09:02:12 PDT 2024
================
@@ -1056,6 +1083,25 @@ void CoroCloner::create() {
// Set up the new entry block.
replaceEntryBlock();
+ // Turn symmetric transfers into musttail calls.
+ for (CallInst *ResumeCall : Shape.SymmetricTransfers) {
+ ResumeCall = cast<CallInst>(VMap[ResumeCall]);
+ ResumeCall->setCallingConv(NewF->getCallingConv());
+ if (TTI.supportsTailCallFor(ResumeCall)) {
+ // FIXME: Could we support symmetric transfer effectively without
+ // musttail?
+ ResumeCall->setTailCallKind(CallInst::TCK_MustTail);
+ }
+
+ // Put a 'ret void' after the call, and split any remaining instructions to
----------------
zmodem wrote:
I'm also concerned with maintenance, that's why I'm pushing back against adding special rules around this intrinsic.
Let's say that we did add an assert checking for non-trivial instructions after `llvm.coro.await.suspend.handle`. If someone were to write a pass which inserts instrumentation after each call instruction to see if the call returns, they now need to treat coros as a special case. (Assuming they notice, by testing their pass on a coroutine.)
It's better if other passes don't have to have special cases for coroutines. I think that's the case with my current patch, because it fits within the existing IR model: function calls don't necessarily return, and when they don't, instructions after the call won't run and the optimizer may remove them. Here's a concrete example: https://godbolt.org/z/M65Ebcfh5
https://github.com/llvm/llvm-project/pull/89751
More information about the cfe-commits
mailing list