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
Copy file name to clipboardExpand all lines: llvm/docs/Coroutines.rst
+15-15Lines changed: 15 additions & 15 deletions
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,7 @@ then destroy it:
37
37
38
38
.. _coroutine frame:
39
39
40
-
In addition to the function stack frame which exists when a coroutine is
40
+
In addition to the function stack frame, which exists when a coroutine is
41
41
executing, there is an additional region of storage that contains objects that
42
42
keep the coroutine state when a coroutine is suspended. This region of storage
43
43
is called the **coroutine frame**. It is created when a coroutine is called
@@ -145,7 +145,7 @@ lowerings:
145
145
yielded values.
146
146
147
147
The coroutine indicates that it has run to completion by returning
148
-
a null continuation pointer. Any yielded values will be `undef`
148
+
a null continuation pointer. Any yielded values will be `undef` and
149
149
should be ignored.
150
150
151
151
- In yield-once returned-continuation lowering, the coroutine must
@@ -159,7 +159,7 @@ passed to the `coro.id` intrinsic, which guarantees a certain size
159
159
and alignment statically. The same buffer must be passed to the
160
160
continuation function(s). The coroutine will allocate memory if the
161
161
buffer is insufficient, in which case it will need to store at
162
-
least that pointer in the buffer; therefore the buffer must always
162
+
least that pointer in the buffer; therefore, the buffer must always
163
163
be at least pointer-sized. How the coroutine uses the buffer may
164
164
vary between suspend points.
165
165
@@ -182,7 +182,7 @@ handling of control-flow must be handled explicitly by the frontend.
182
182
In this lowering, a coroutine is assumed to take the current `async context` as
183
183
one of its arguments (the argument position is determined by
184
184
`llvm.coro.id.async`). It is used to marshal arguments and return values of the
185
-
coroutine. Therefore an async coroutine returns `void`.
185
+
coroutine. Therefore, an async coroutine returns `void`.
186
186
187
187
.. code-block:: llvm
188
188
@@ -321,7 +321,7 @@ The `cleanup` block destroys the coroutine frame. The `coro.free`_ intrinsic,
321
321
given the coroutine handle, returns a pointer of the memory block to be freed or
322
322
`null` if the coroutine frame was not allocated dynamically. The `cleanup`
323
323
block is entered when coroutine runs to completion by itself or destroyed via
324
-
call to the `coro.destroy`_ intrinsic.
324
+
a call to the `coro.destroy`_ intrinsic.
325
325
326
326
The `suspend` block contains code to be executed when coroutine runs to
327
327
completion or suspended. The `coro.end`_ intrinsic marks the point where
@@ -337,7 +337,7 @@ Coroutine Transformation
337
337
------------------------
338
338
339
339
One of the steps of coroutine lowering is building the coroutine frame. The
340
-
def-use chains are analyzed to determine which objects need be kept alive across
340
+
def-use chains are analyzed to determine which objects need to be kept alive across
341
341
suspend points. In the coroutine shown in the previous section, use of virtual register
342
342
`%inc` is separated from the definition by a suspend point, therefore, it
343
343
cannot reside on the stack frame since the latter goes away once the coroutine
@@ -532,7 +532,7 @@ as follows:
532
532
ret void
533
533
}
534
534
535
-
If different cleanup code needs to get executed for different suspend points,
535
+
If different cleanup code needs to be executed for different suspend points,
536
536
a similar switch will be in the `f.destroy` function.
537
537
538
538
.. note ::
@@ -740,7 +740,7 @@ looks like this:
740
740
<SUSPEND final=true> // injected final suspend point
741
741
}
742
742
743
-
and python iterator `__next__` would look like:
743
+
and Python iterator `__next__` would look like:
744
744
745
745
.. code-block:: c++
746
746
@@ -829,7 +829,7 @@ A swifterror alloca or parameter can only be loaded, stored, or passed as a swif
829
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
830
831
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.
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
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.
834
834
835
835
Intrinsics
@@ -965,7 +965,7 @@ Semantics:
965
965
Using this intrinsic on a coroutine that does not have a coroutine promise
966
966
leads to undefined behavior. It is possible to read and modify coroutine
967
967
promise of the coroutine which is currently executing. The coroutine author and
968
-
a coroutine user are responsible to makes sure there is no data races.
968
+
a coroutine user are responsible for ensuring no data races.
969
969
970
970
Example:
971
971
""""""""
@@ -1181,7 +1181,7 @@ Overview:
1181
1181
"""""""""
1182
1182
1183
1183
The '``llvm.coro.alloc``' intrinsic returns `true` if dynamic allocation is
1184
-
required to obtain a memory for the coroutine frame and `false` otherwise.
1184
+
required to obtain memory for the coroutine frame and `false` otherwise.
1185
1185
This is not supported for returned-continuation coroutines.
1186
1186
1187
1187
Arguments:
@@ -1628,7 +1628,7 @@ The second argument should be `true` if this coro.end is in the block that is
1628
1628
part of the unwind sequence leaving the coroutine body due to an exception and
1629
1629
`false` otherwise.
1630
1630
1631
-
The third argument if present should specify a function to be called.
1631
+
The third argument, if present, should specify a function to be called.
1632
1632
1633
1633
If the third argument is present, the remaining arguments are the arguments to
1634
1634
the function call.
@@ -1700,7 +1700,7 @@ Semantics:
1700
1700
If a coroutine that was suspended at the suspend point marked by this intrinsic
1701
1701
is resumed via `coro.resume`_ the control will transfer to the basic block
1702
1702
of the 0-case. If it is resumed via `coro.destroy`_, it will proceed to the
1703
-
basic block indicated by the 1-case. To suspend, coroutine proceed to the
1703
+
basic block indicated by the 1-case. To suspend, coroutine proceeds to the
1704
1704
default label.
1705
1705
1706
1706
If suspend intrinsic is marked as final, it can consider the `true` branch
@@ -1717,7 +1717,7 @@ unreachable and can perform optimizations that can take advantage of that fact.
1717
1717
Overview:
1718
1718
"""""""""
1719
1719
1720
-
The '``llvm.coro.save``' marks the point where a coroutine need to update its
1720
+
The '``llvm.coro.save``' marks the point where a coroutine needs to update its
1721
1721
state to prepare for resumption to be considered suspended (and thus eligible
1722
1722
for resumption). It is illegal to merge two '``llvm.coro.save``' calls unless their
1723
1723
'``llvm.coro.suspend``' users are also merged. So '``llvm.coro.save``' is currently
@@ -1793,7 +1793,7 @@ The fourth to six argument are the arguments for the third argument.
1793
1793
Semantics:
1794
1794
""""""""""
1795
1795
1796
-
The result of the intrinsic are mapped to the arguments of the resume function.
1796
+
The results of the intrinsic are mapped to the arguments of the resume function.
1797
1797
Execution is suspended at this intrinsic and resumed when the resume function is
0 commit comments