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

Mircea Trofin via cfe-commits cfe-commits at lists.llvm.org
Fri May 3 18:31:00 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
----------------
mtrofin wrote:

> That still sounds like the remark would not target the compiler user, but the developer of the compiler tool -- and that's not really what optimization remarks are for.

Not sure if that's the case anymore, they do have a yaml outputter.

But that's besides the point. I think I can see this your way: in our running example, if I worked on coverage, and knew to write the ORE post-processor, I would also know to fix my coverage instrumenter to recognize not to place instructions in the wrong place. (I realize there are other cases where passes are OK to stay agnostic despite losing instructions here, but in the coverage scenario that's not the case any way you look at it). The main thing is how to figure I may have a problem, and really the fix there is "integration testing", really.

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


More information about the cfe-commits mailing list