Extend retcon.once coroutines lowering to optionally produce a normal result
#66333
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
llvmbot
added
clang
|
@llvm/pr-subscribers-clang-codegen @llvm/pr-subscribers-mlir ChangesOne of the main user of these kind of coroutines is swift. There yield-once (`retcon.once`) coroutines are used to temporary "expose" pointers to internal fields of various objects creating borrow scopes.However, in some cases it might be useful also to allow these coroutines to produce a normal result, however, there is no way to represent this (as compared to switched-resume kind of coroutines where C++ The extension is simple: we simply allow continuation function to have non-void result and accept optional extra arguments to
|
ChuanqiXu9
reviewed
Sep 14, 2023
ChuanqiXu9
reviewed
Sep 14, 2023
There was a problem hiding this comment.
One of the main user of these kind of coroutines is swift. There yield-once (retcon.once) coroutines are used to temporary "expose" pointers to internal fields of various objects creating borrow scopes.
However, in some cases it might be useful also to allow these coroutines to produce a normal result, however, there is no way to represent this (as compared to switched-resume kind of coroutines where C++ co_return is transformed to a member / callback call on promise object).
Out of curiousity, why don't we have the problem in the normal return continuation ABI?
The problem happens when the value is directly used in |
I still don't understand the motivation fully. Do you say we don't have the problem naturally? Or could you show some motivation examples? (In LLVM IR?) |
This one is problematic: define {ptr, ptr} @g(ptr %buffer, ptr %ptr, i8 %val) presplitcoroutine {
entry:
%temp = alloca i32, align 4
%id = call token @llvm.coro.id.retcon.once(i32 8, i32 8, ptr %buffer, ptr @prototype2, ptr @allocate, ptr @deallocate)
%hdl = call ptr @llvm.coro.begin(token %id, ptr null)
%oldvalue = load i32, ptr %ptr
store i32 %oldvalue, ptr %temp
%unwind = call i1 (...) @llvm.coro.suspend.retcon.i1(ptr %temp)
br i1 %unwind, label %cleanup, label %cont
cont:
%newvalue = load i32, ptr %temp
store i32 %newvalue, ptr %ptr
br label %cleanup
cleanup:
call i1 (ptr, i1, ...) @llvm.coro.end(ptr %hdl, i1 0, i8 %val)
unreachable
}but this one is not (cleanup will be split before define {ptr, ptr} @g(ptr %buffer, ptr %ptr, i8 %val) presplitcoroutine {
entry:
%temp = alloca i32, align 4
%id = call token @llvm.coro.id.retcon.once(i32 8, i32 8, ptr %buffer, ptr @prototype2, ptr @allocate, ptr @deallocate)
%hdl = call ptr @llvm.coro.begin(token %id, ptr null)
%oldvalue = load i32, ptr %ptr
store i32 %oldvalue, ptr %temp
%unwind = call i1 (...) @llvm.coro.suspend.retcon.i1(ptr %temp)
br i1 %unwind, label %cleanup, label %cont
cont:
%newvalue = load i32, ptr %temp
store i32 %newvalue, ptr %ptr
br label %cleanup
cleanup:
%newval = add i8 %val, 42
call i1 (ptr, i1, ...) @llvm.coro.end(ptr %hdl, i1 0, i8 %newval)
unreachable
}This one is problematic as well: define {ptr, ptr} @g(ptr %buffer, ptr %ptr, i8 %val) presplitcoroutine {
entry:
%temp = alloca i32, align 4
%id = call token @llvm.coro.id.retcon.once(i32 8, i32 8, ptr %buffer, ptr @prototype2, ptr @allocate, ptr @deallocate)
%hdl = call ptr @llvm.coro.begin(token %id, ptr null)
%oldvalue = load i32, ptr %ptr
store i32 %oldvalue, ptr %temp
%newval = add i8 %val, 42
%unwind = call i1 (...) @llvm.coro.suspend.retcon.i1(ptr %temp)
br i1 %unwind, label %cleanup, label %cont
cont:
%newvalue = load i32, ptr %temp
store i32 %newvalue, ptr %ptr
br label %cleanup
cleanup:
call i1 (ptr, i1, ...) @llvm.coro.end(ptr %hdl, i1 0, i8 %newval)
unreachable
}All these are "new" cases I would say, everything else is handled via current split approach. |
|
Oh, I am wondering if we have misunderstandings. I am not asking the reason why we don't have the problem which is discussing in the change of CoroFrame.cpp in return continuation ABI. I understand that fully. What make me curious is the motivation case of the PR. I mean what can be presented in retcon.once ABI after the PR which is impossible/hard before. And how do we handle that in retcon ABI. Sorry for confusion. |
Well, the PR allows The particular usecase from Swift is as follows:
The particular example of coroutine lowering could be seen in https://github.com/llvm/llvm-project/pull/66333/files#diff-70da911ce77807c88cdfcf3578aa2a569e131c99653488d148a5fd6e9b0df169 |
|
Got it. Thanks. Then I am wondering how about the |
Ah, ok. The current PR is only for |
|
Got it. Thanks for the explanation : ) |
…y) return values from `retcon.once` coroutines.
asl
force-pushed
the
coro-retcon-once-return
branch
from
cd7b571
to
5c30195
Compare
ZijunZhaoCCK
pushed a commit
to ZijunZhaoCCK/llvm-project
that referenced
this pull request
Sep 19, 2023
…al result (llvm#66333) One of the main user of these kind of coroutines is swift. There yield-once (`retcon.once`) coroutines are used to temporary "expose" pointers to internal fields of various objects creating borrow scopes. However, in some cases it might be useful also to allow these coroutines to produce a normal result, but there is no convenient way to represent this (as compared to switched-resume kind of coroutines where C++ `co_return` is transformed to a member / callback call on promise object). The extension is simple: we allow continuation function to have a non-void result and accept optional extra arguments via a special `llvm.coro.end.result` intrinsic that would essentially forward them as normal results.
asl
added a commit
to asl/llvm-project
that referenced
this pull request
Feb 5, 2024
…al result (llvm#66333) One of the main user of these kind of coroutines is swift. There yield-once (`retcon.once`) coroutines are used to temporary "expose" pointers to internal fields of various objects creating borrow scopes. However, in some cases it might be useful also to allow these coroutines to produce a normal result, but there is no convenient way to represent this (as compared to switched-resume kind of coroutines where C++ `co_return` is transformed to a member / callback call on promise object). The extension is simple: we allow continuation function to have a non-void result and accept optional extra arguments via a special `llvm.coro.end.result` intrinsic that would essentially forward them as normal results.
asl
added a commit
to asl/llvm-project
that referenced
this pull request
Mar 22, 2024
…al result (llvm#66333) One of the main user of these kind of coroutines is swift. There yield-once (`retcon.once`) coroutines are used to temporary "expose" pointers to internal fields of various objects creating borrow scopes. However, in some cases it might be useful also to allow these coroutines to produce a normal result, but there is no convenient way to represent this (as compared to switched-resume kind of coroutines where C++ `co_return` is transformed to a member / callback call on promise object). The extension is simple: we allow continuation function to have a non-void result and accept optional extra arguments via a special `llvm.coro.end.result` intrinsic that would essentially forward them as normal results.
rxwei
pushed a commit
to apple/llvm-project
that referenced
this pull request
Mar 27, 2024
* Update coroutine intrinsics documentation and few remaining tests to opaque pointers (llvm#65698) * Extend `retcon.once` coroutines lowering to optionally produce a normal result (llvm#66333) One of the main user of these kind of coroutines is swift. There yield-once (`retcon.once`) coroutines are used to temporary "expose" pointers to internal fields of various objects creating borrow scopes. However, in some cases it might be useful also to allow these coroutines to produce a normal result, but there is no convenient way to represent this (as compared to switched-resume kind of coroutines where C++ `co_return` is transformed to a member / callback call on promise object). The extension is simple: we allow continuation function to have a non-void result and accept optional extra arguments via a special `llvm.coro.end.result` intrinsic that would essentially forward them as normal results.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
One of the main user of these kind of coroutines is swift. There yield-once (
retcon.once) coroutines are used to temporary "expose" pointers to internal fields of various objects creating borrow scopes.However, in some cases it might be useful also to allow these coroutines to produce a normal result, however, there is no way to represent this (as compared to switched-resume kind of coroutines where C++
co_returnis transformed to a member / callback call on promise object).The extension is simple: we allow continuation function to have a non-void result and accept optional extra arguments to
llvm.coro.endintrinsic that would essentially forward them as normal results. Everything is backward compatible in terms of LLVM C++ API (as we only madellvm.coro.endintrinsic variadic), so no changes in downstream projects are expected.