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