You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Coroutines][Docs] Add a discussion on the handling of certain parameter attribs
ByVal arguments and Swifterror require special handling in the coroutine
passes. The goal of this section is to provide a description of how these
parameter attributes are handled.
Copy file name to clipboardExpand all lines: llvm/docs/Coroutines.rst
+22Lines changed: 22 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -810,6 +810,28 @@ The LLVM IR for a coroutine using a Coroutine with a custom ABI looks like:
810
810
ret ptr %hdl
811
811
}
812
812
813
+
Parameter Attributes
814
+
============
815
+
Some parameter attributes, used to communicate additional information about the result or parameters of a function, require special handling.
816
+
817
+
ByVal
818
+
---------------------------------
819
+
A ByVal parameter on an argument indicates that the pointer parameter should really be passed by value to the function.
820
+
Prior to the coroutine transforms loads and stores to/from the pointer are generated where the value is needed.
821
+
Consequently, a ByVal argument is treated much like an alloca.
822
+
Space is allocated for it on the coroutine frame and the uses of the argument pointer are replaced with a pointer to the coroutine frame.
823
+
824
+
Swift Error
825
+
---------------------------------
826
+
Clang supports the swiftcall calling convention in many common targets, and a user could call a function that takes a swifterror argument from a C++ coroutine.
827
+
The swifterror parameter attribute exists to model and optimize Swift error handling.
828
+
A swifterror alloca or parameter can only be loaded, stored, or passed as a swifterror call argument, and a swifterror call argument can only be a direct reference to a swifterror alloca or parameter.
829
+
These rules, not coincidentally, mean that you can always perfectly model the data flow in the alloca, and LLVM CodeGen actually has to do that in order to emit code.
830
+
831
+
For coroutine lowering the default treatment of allocas breaks those rules — splitting will try to replace the alloca with an entry in the coro frame, which can lead to trying to pass that as a swifterror argument.
832
+
To pass a swifterror argument in a split function, we need to still have the alloca around; but we also potentially need the coro frame slot, since useful data can (in theory) be stored in the swifterror alloca slot across suspensions in the presplit coroutine.
833
+
When split a coroutine it is consequently necessary to keep both the frame slot as well as the alloca itself and then keep them in sync.
0 commit comments