[clang] [llvm] [coro] Lower `llvm.coro.await.suspend.handle` to resume with tail call (PR #89751)

[Mircea Trofin via llvm-commits]

================
@@ -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
----------------
mtrofin wrote:

> But in that case the problem was kind of the opposite, right? Instructions between the resume and suspend blocked the musttail optimization. The problem was not whether those instructions would have been executed or not, but that they were inserted in a place where it wasn't allowed due to special constraints on this intrinsic.
> The idea with my patch is to eliminate that problem by not having special restrictions about instructions after the intrinsic, they just won't be executed because control continues in the resumed function and doesn't come back.

I think I see where the disconnect comes from. You're referring to the desired outcome for coro: tailcalls being ensured. I agree with that, but I'm concerned with maintenance: suppose some other pass does what PGOInstrument did, in the future. Just like with coro, the potential for a undesired interaction between coro and their pass isn't known to them. How easy would it be to discover they made incorrect assumptions in their pass, diagnose and fix?

https://github.com/llvm/llvm-project/pull/89751