================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
