Skip to content

Commit 4976be8

Browse files
authored
Merge pull request swiftlang#81747 from gottesmm/pr-021007354c4c9e191bcb63c8573c668dc20a40fd
[sil][docs] Add documentation about sil_implicit_leading_param.
2 parents 7387f85 + 56aa981 commit 4976be8

File tree

2 files changed

+42
-3
lines changed

2 files changed

+42
-3
lines changed

docs/SIL/SIL.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -457,9 +457,10 @@ The ownership kind of a value is statically determined:
457457
...
458458
```
459459

460-
- The ownership of most instruction results is statically defined. For example
461-
`copy_value` always produces an owned value, whereas `begin_borrow` always
462-
produces a guaranteed value.
460+
- The ownership of most instruction results can be statically determined from
461+
the instruction's kind and the offset of the value in the result tuple. For
462+
example `copy_value` has only one result and that result is always an owned
463+
value, whereas `begin_borrow` always produces a guaranteed value.
463464

464465
- Forwarding instructions: some instructions work with both, owned and
465466
guaranteed ownership, and "forward" the ownership from their operand(s) to

docs/SIL/Types.md

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -431,6 +431,44 @@ in the callee.
431431
`@sil_isolated` since a function cannot be isolated to multiple
432432
actors at the same time.
433433
434+
- SIL functions may optionally mark a function parameter as
435+
`@sil_implicit_leading_param`. A SIL generator places this on a parameter
436+
that is used to represent a parameter that is implicitly generated by the
437+
generator at a full call site. Since they can only appear at the full call
438+
site, a `@sil_implicit_leading_param` can only appear in between the
439+
indirect result parameters and the direct parameters. For example the
440+
following swift code that uses `nonisolated(nonsending)`:
441+
442+
```
443+
nonisolated(nonsending)
444+
func f(_ x: DirectParam) -> IndirectResult {
445+
...
446+
}
447+
```
448+
449+
would translate to the following SIL:
450+
451+
```
452+
sil [ossa] @f : $@convention(thin) @async (
453+
@sil_isolated @sil_implicit_leading_param @guaranteed Optional<any Actor>,
454+
@guaranteed DirectParam
455+
) -> @out IndirectResult {
456+
bb0(%0 : $*IndirectResult, %1 : @guaranteed $Optional<Actor>, %2 : @guaranteed $DirectParam):
457+
... use %0 ...
458+
}
459+
```
460+
461+
Notice how there is an `@sil_isolated` `@sil_implicit_leading_param`
462+
parameter that was inserted by SILGen to implicitly take in the caller's
463+
actor of f.
464+
465+
NOTE: By design SILOptimizer passes should ignore
466+
`@sil_implicit_leading_param`. Instead, it should only be analyzed as a
467+
normal parameter. So as an example, in f above the implicit parameter should
468+
be treated by the optimizer just as any other isolated parameter. This is
469+
solely SILGen using SIL as a data structure. TODO: Can this be removed by
470+
SILGen so SILOptimizer passes cannot even see it?
471+
434472
### Async Functions
435473
436474
SIL function types may be `@async`. `@async` functions run inside async

0 commit comments

Comments
 (0)