Skip to content

Commit 0398ad4

Browse files
[llvm] Proofread Coroutines.rst (#151906)
1 parent 35dd889 commit 0398ad4

File tree

1 file changed

+15
-15
lines changed

1 file changed

+15
-15
lines changed

llvm/docs/Coroutines.rst

Lines changed: 15 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ then destroy it:
3737
3838
.. _coroutine frame:
3939

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
4141
executing, there is an additional region of storage that contains objects that
4242
keep the coroutine state when a coroutine is suspended. This region of storage
4343
is called the **coroutine frame**. It is created when a coroutine is called
@@ -145,7 +145,7 @@ lowerings:
145145
yielded values.
146146

147147
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
149149
should be ignored.
150150

151151
- In yield-once returned-continuation lowering, the coroutine must
@@ -159,7 +159,7 @@ passed to the `coro.id` intrinsic, which guarantees a certain size
159159
and alignment statically. The same buffer must be passed to the
160160
continuation function(s). The coroutine will allocate memory if the
161161
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
163163
be at least pointer-sized. How the coroutine uses the buffer may
164164
vary between suspend points.
165165

@@ -182,7 +182,7 @@ handling of control-flow must be handled explicitly by the frontend.
182182
In this lowering, a coroutine is assumed to take the current `async context` as
183183
one of its arguments (the argument position is determined by
184184
`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`.
186186

187187
.. code-block:: llvm
188188
@@ -321,7 +321,7 @@ The `cleanup` block destroys the coroutine frame. The `coro.free`_ intrinsic,
321321
given the coroutine handle, returns a pointer of the memory block to be freed or
322322
`null` if the coroutine frame was not allocated dynamically. The `cleanup`
323323
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.
325325

326326
The `suspend` block contains code to be executed when coroutine runs to
327327
completion or suspended. The `coro.end`_ intrinsic marks the point where
@@ -337,7 +337,7 @@ Coroutine Transformation
337337
------------------------
338338

339339
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
341341
suspend points. In the coroutine shown in the previous section, use of virtual register
342342
`%inc` is separated from the definition by a suspend point, therefore, it
343343
cannot reside on the stack frame since the latter goes away once the coroutine
@@ -532,7 +532,7 @@ as follows:
532532
ret void
533533
}
534534
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,
536536
a similar switch will be in the `f.destroy` function.
537537

538538
.. note ::
@@ -740,7 +740,7 @@ looks like this:
740740
<SUSPEND final=true> // injected final suspend point
741741
}
742742
743-
and python iterator `__next__` would look like:
743+
and Python iterator `__next__` would look like:
744744

745745
.. code-block:: c++
746746

@@ -829,7 +829,7 @@ A swifterror alloca or parameter can only be loaded, stored, or passed as a swif
829829
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.
830830

831831
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.
833833
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.
834834

835835
Intrinsics
@@ -965,7 +965,7 @@ Semantics:
965965
Using this intrinsic on a coroutine that does not have a coroutine promise
966966
leads to undefined behavior. It is possible to read and modify coroutine
967967
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.
969969

970970
Example:
971971
""""""""
@@ -1181,7 +1181,7 @@ Overview:
11811181
"""""""""
11821182

11831183
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.
11851185
This is not supported for returned-continuation coroutines.
11861186

11871187
Arguments:
@@ -1628,7 +1628,7 @@ The second argument should be `true` if this coro.end is in the block that is
16281628
part of the unwind sequence leaving the coroutine body due to an exception and
16291629
`false` otherwise.
16301630

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.
16321632

16331633
If the third argument is present, the remaining arguments are the arguments to
16341634
the function call.
@@ -1700,7 +1700,7 @@ Semantics:
17001700
If a coroutine that was suspended at the suspend point marked by this intrinsic
17011701
is resumed via `coro.resume`_ the control will transfer to the basic block
17021702
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
17041704
default label.
17051705

17061706
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.
17171717
Overview:
17181718
"""""""""
17191719

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
17211721
state to prepare for resumption to be considered suspended (and thus eligible
17221722
for resumption). It is illegal to merge two '``llvm.coro.save``' calls unless their
17231723
'``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.
17931793
Semantics:
17941794
""""""""""
17951795

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.
17971797
Execution is suspended at this intrinsic and resumed when the resume function is
17981798
called.
17991799

0 commit comments

Comments
 (0)