[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