@@ -24,22 +24,13 @@ instructions.
24
24
25
25
%async-start = (f32[64], f32[32], s32[]) async-start(f32[64] %operand),
26
26
calls=%async_op
27
- %async-done = f32[32] async-done((f32[64], f32[32], s32[]) %async-start),
28
- calls=%async_op
27
+ %async-done = f32[32] async-done((f32[64], f32[32], s32[]) %async-start)
29
28
```
30
29
31
30
In the representation above, only ` async-start ` has a called computation since
32
31
it is trivial to find what the ` async-done ` does by following its operand to
33
32
find the corresponding ` async-start ` to find the called computation.
34
33
35
- Today both ` async-start ` and ` async-done ` have a called computation attribute,
36
- but long term we plan to keep it only for ` async-start ` , since it is trivial
37
- to find what the ` async-done ` does by following its operand to find the
38
- corresponding ` async-start ` to find the called computation.
39
-
40
- > [ !NOTE]
41
- > Tracked as b/302594825 internally.
42
-
43
34
Also note
44
35
that the first element in the output tuple of ` async-start ` aliases with the
45
36
operand, so the buffer stays alive until at least the async-done instruction.
@@ -102,10 +93,8 @@ to the following and the two can be parsed to the same representation:
102
93
(f32[64], f32[32], s32[]) %op-start),
103
94
op_specific_attr=”foo”
104
95
%op-update1 = (f32[64], f32[32], s32[]) op-update(
105
- (f32[64], f32[32], s32[]) %op-update0),
106
- op_specific_attr=”foo”
107
- %op-done = f32[32] op-done((f32[64], f32[32], s32[]) %op-update1),
108
- op_specific_attr=”foo”
96
+ (f32[64], f32[32], s32[]) %op-update0)
97
+ %op-done = f32[32] op-done((f32[64], f32[32], s32[]) %op-update1)
109
98
110
99
```
111
100
0 commit comments