Skip to content

PR for llvm/llvm-project#56301 #644

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 27, 2023
Merged

PR for llvm/llvm-project#56301 #644

merged 2 commits into from
Aug 27, 2023

Conversation

llvmbot
Copy link
Member

@llvmbot llvmbot commented Aug 25, 2023

… not empty

Close llvm/llvm-project#56301
Close llvm/llvm-project#64151

See the summary and the discussion of https://reviews.llvm.org/D157070
to get the full context.

As @rjmccall pointed out, the key point of the root cause is that
currently we didn't implement the semantics for '@llvm.coro.save' well
("after the await-ready returns false, the coroutine is considered to be
suspended ") well.
Since the semantics implies that we (the compiler) shouldn't write the
spills into the coroutine frame in the await_suspend. But now it is possible
due to some combinations of the optimizations so the semantics are
broken. And the inlining is the root optimization of such optimizations.
So in this patch, we tried to add the `noinline` attribute to the
await_suspend call.

Also as an optimization, we don't add the `noinline` attribute to the
await_suspend call if the awaiter is an empty class. This should be
correct since the programmers can't access the local variables in
await_suspend if the awaiter is empty. I think this is necessary for the
performance since it is pretty common.

Another potential optimization is:

    call @llvm.coro.await_suspend(ptr %awaiter, ptr %handle,
                                  ptr @awaitSuspendFn)

Then it is much easier to perform the safety analysis in the middle
end.
If it is safe to inline the call to awaitSuspend, we can replace it
in the CoroEarly pass. Otherwise we could replace it in the CoroSplit
pass.

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D157833
… regressions

The fix we sent for llvm/llvm-project#56301
may bring performance regressions. But we didn't mention it in the
ReleaseNotes so that users may get confused. e.g,
llvm/llvm-project#64933. So this patch
mentions the possible side effect and the potential solutions in
llvm/llvm-project#64945 to avoid
misunderstandings.
@llvmbot
Copy link
Member Author

llvmbot commented Aug 25, 2023

@web-flow What do you think about merging this PR to the release branch?

@ChuanqiXu9
Copy link
Member

I'd like to backport this patch since the issue had been reported several places and relatively severe (I admit it looks more severe than I think initially).

@tru tru merged commit 6998ecd into release/17.x Aug 27, 2023
@tru tru deleted the ChuanqiXu9-Resolve56301 branch August 27, 2023 08:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[bug] clang miscompiles coroutine awaiter, moving write across a critical section
3 participants