[ownership] Implement movable guaranteed scopes in ossa. #29875

gottesmm · 2020-02-17T05:21:27Z

This patch implements movable guaranteed scopes in ossa. This pattern is
currently not generated anywhere in the compiler, but my hope is to begin
emitting these in SemanticARCOpts. The idea is that these model true phi nodes
and thus can be used to fuse multiple guaranteed scopes into one using br
instructions. This is treated similarly to how owned instructions are forwarded
through /all/ terminators. This will enable us to use the SILSSAUpdater with
guaranteed arguments as well as enable the expression of sets of borrow scopes
that minimally jointly-dominate a guaranteed argument. This will enable us to
express +0 merge points like the following:

bb1:
  %0a = begin_borrow %0 : $Klass
  br bb3(%0a : $Klass)

bb2:
  %1a = load_borrow %1 : $*Klass
  br bb3(%1a : $Klass)

bb3(%2 : @guaranteed $Klass)
  ...
  end_borrow %2 : $Klass

I describe below what the semantics of guaranteed block arguments were
previously, what they are now, and a little bit of interesting things from a
semantic perspective around implicit sub-scope users.

Before this patch in ossa, guaranteed block arguments had two different sets of
semantics:

Given a checked_cast_br or a switch_enum, the guaranteed block argument was
treated like a forwarding instruction. As such, the guaranteed argument's did
not require an end_borrow and its uses were validated as part of the use list
of the switch_enum/checked_cast_br operand's borrow introducer. It also was
not classified as a BorrowScopeValueIntroducer since it was not introducing a
new scope.
Given any other predecessor terminator, we treated the guaranteed argument as
a complete sub-scope of its incoming values. Thus we required the guaranteed
argument to have its lifetime eneded by an end_borrow and that all incoming
values of the guaranteed argument to come from a borrow introducer whose set
of jointly post-dominating end_borrows also jointly post-dominates the set of
end_borrows associated with the guaranteed argument itself. Consider the
following example:

bb0:
  %1 = begin_borrow %foo : $Foo   // (1)
  %2 = begin_borrow %foo2 : $Foo2 // (2)
  cond_br ..., bb1, bb2

bb1:
  br bb3(%1 : $Foo)

bb2:
  br bb3(%2 : $Foo)

bb3(%3 : @guaranteed $Foo)
  ...
  end_borrow %3 : $Foo            // (3)
  end_borrow %2 : $Foo            // (4)
  end_borrow %1 : $Foo            // (5)
  ...

Notice how due to SSA, (1) and (2) must dominate (4) and (5) and thus must
dominate bb3, preventing the borrows from existing within bb1, bb2.

This dominance property is actively harmful to expressivity in SIL since it
means that guaranteed arguments can not be used to express (without contortion)
sil code patterns where an argument is jointly-dominated by a minimal set of
guaranteed incoming values. For instance, consider the following SIL example:

bb0:
  cond_br ..., bb1, bb2

bb1:
  %0 = load [copy] %globalAddr : $Foo
  br bb3(%0 : $Foo)

bb2:
  %1 = copy_value %guaranteedFunctionArg : $Foo
  br bb3(%1 : $Foo):

bb3(%2 : @owned $Foo):
  apply %useFoo(%2)
  destroy_value %2 : $Foo

As a quick proof: Assume the previous rules for guaranteed arguments. Then to
promote the load [copy] -> load_borrow and the copy_value to a begin_borrow, we
would need to place an end_borrow in bb3. But neither bb1 or bb2 dominates bb3,
so we would violate SSA dominance rules.

To enable SIL to express this pattern, we introduce a third rule for terminator
in ossa that applies only to branch insts. All other branches that obeyed the
previous rules (cond_br), still follow the old rule. This is not on purpose, I
am just being incremental and changing things as I need to. Specifically,
guaranteed arguments whose incoming values are defined by branch instructions
now act as a move on guaranteed values. The intuition here is that these
arguments are acting as true phis in an SSA sense and thus are just new names
for the incoming values. This implies since it is just a new name (not a
semantic change) that the guaranteed incoming value's guaranteed scopes should
be fused into one scope. The natural way to model this is by treating branch
insts as consuming guaranteed values. This then lets us express the example
above without using copies as follows:

bb0:
  cond_br ..., bb1, bb2

bb1:
  %0 = load_borrow %globalAddr : $Foo
  br bb3(%0 : $Foo) // consumes %0 and acts as %0's end_borrow.

bb2:
  // We need to introduce a new begin_borrow here since function
  // arguments are required to never be consumed.
  %1 = begin_borrow %guaranteedFunctionArg : $Foo
  br bb3(%1 : $Foo) // consumes %1 and acts as %1's end_borrow

// %2 continues the guaranteed scope of %0, %1. This time fused with one name.
bb3(%2 : @guaranteed $Foo):
  apply %useFoo(%2)
  // End the lifetime of %2 (which implicitly ends the lifetime of %0, %1).
  end_borrow %2 : $Foo
  ...

The main complication for users is that now when attempting to discover the set
of implicit users on an owned or guaranteed value caused by their usage as an
argument of a borrow introducer like begin_borrow. For those who are unaware, a
begin_borrow places an implicit requirement on its parent value that the parent
value is alive for the entire part of the CFG where this begin_borrow is
live. Previously, one could just look for the end_borrows of the
begin_borrow. Now one must additionally look for consuming branch insts. This is
because the original value that is being borrowed from must be alive over the
entire web of guaranteed values. That is the entire web of guaranteed values act
as a liveness requirement on the begin_borrow's operand.

The way this is implemented is given a use that we are validating, if the use is
a BorrowScopeOperand (1), we see if the borrow scope operand consumes the given
guaranteed scope and forwards it into a borrow scope introducer. If so, we add
the list of consuming uses of the borrow scope introducer to the worklist to
visit and then iterate.

In order to avoid working with cycles, for now, the ownership verifier bans
liveness requiring uses that have cycles in them. This still allows us to have
loop carried guaranteed values.

(1) A BorrowScopeOperand is a concept that represents an operand to a SIL
instruction that begins a guaranteed scope of some sort. All BorrowScopeOperand
are thus at a minimum able to compute a compile time the static region in which
they implicitly use their operands. NOTE: We do not require the scope to be
represented as a SILValue in the same function.

We achieve some nice benefit by introducing this. Specifically:

We can optimize the pattern I mentioned above. This is a common pattern in
many frameworks that want to return a default object if a computation fails
(with the default object usually being some sort of global or static
var). This will let us optimize that case when the global is a let global.
The SSA Updater can now be used with guaranteed values without needing to
introduce extra copies. This will enable predictable mem opts to introduce
less copies and for semantic arc opts to optimize the remaining copies that
PMO exposes but does not insert itself.

rdar://56720519

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

gottesmm · 2020-02-17T05:22:47Z

@swift-ci test

gottesmm · 2020-02-17T05:23:03Z

I am not expecting this to result in any /true/ differences since I don't think any passes produce this today.

gottesmm · 2020-02-17T05:23:08Z

@swift-ci benchmark

gottesmm · 2020-02-17T05:23:14Z

@swift-ci test source compatibility

swift-ci · 2020-02-17T05:45:15Z

Performance: -O

Code size: -O

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
DropLastArrayLazy	4	5	+25.0%	0.80x

Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	3329	2781	-16.5%	1.20x (?)

Code size: -Osize

Performance: -Onone

Code size: -swiftlibs

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

swift-ci · 2020-02-17T06:17:32Z

Build failed
Swift Test OS X Platform
Git Sha - c98c88c5e580cb13cfccdbd6219f24fb26e6bc2c

swift-ci · 2020-02-17T06:38:20Z

Build failed
Swift Test Linux Platform
Git Sha - c98c88c5e580cb13cfccdbd6219f24fb26e6bc2c

@guaranteed

This patch implements movable guaranteed scopes in ossa. This pattern is currently not generated anywhere in the compiler, but my hope is to begin emitting these in SemanticARCOpts. The idea is that these model true phi nodes and thus can be used to fuse multiple guaranteed scopes into one using br instructions. This is treated similarly to how owned instructions are forwarded through /all/ terminators. This will enable us to use the SILSSAUpdater with guaranteed arguments as well as enable the expression of sets of borrow scopes that minimally jointly-dominate a guaranteed argument. This will enable us to express +0 merge points like the following: ``` bb1: %0a = begin_borrow %0 : $Klass br bb3(%0a : $Klass) bb2: %1a = load_borrow %1 : $*Klass br bb3(%1a : $Klass) bb3(%2 : @guaranteed $Klass) ... end_borrow %2 : $Klass ``` I describe below what the semantics of guaranteed block arguments were previously, what they are now, and a little bit of interesting things from a semantic perspective around implicit sub-scope users. Before this patch in ossa, guaranteed block arguments had two different sets of semantics: 1. Given a checked_cast_br or a switch_enum, the guaranteed block argument was treated like a forwarding instruction. As such, the guaranteed argument's did not require an end_borrow and its uses were validated as part of the use list of the switch_enum/checked_cast_br operand's borrow introducer. It also was not classified as a BorrowScopeValueIntroducer since it was not introducing a new scope. 2. Given any other predecessor terminator, we treated the guaranteed argument as a complete sub-scope of its incoming values. Thus we required the guaranteed argument to have its lifetime eneded by an end_borrow and that all incoming values of the guaranteed argument to come from a borrow introducer whose set of jointly post-dominating end_borrows also jointly post-dominates the set of end_borrows associated with the guaranteed argument itself. Consider the following example: ``` bb0: %1 = begin_borrow %foo : $Foo // (1) %2 = begin_borrow %foo2 : $Foo2 // (2) cond_br ..., bb1, bb2 bb1: br bb3(%1 : $Foo) bb2: br bb3(%2 : $Foo) bb3(%3 : @guaranteed $Foo) ... end_borrow %3 : $Foo // (3) end_borrow %2 : $Foo // (4) end_borrow %1 : $Foo // (5) ... ``` Notice how due to SSA, (1) and (2) must dominate (4) and (5) and thus must dominate bb3, preventing the borrows from existing within bb1, bb2. This dominance property is actively harmful to expressivity in SIL since it means that guaranteed arguments can not be used to express (without contortion) sil code patterns where an argument is jointly-dominated by a minimal set of guaranteed incoming values. For instance, consider the following SIL example: ``` bb0: cond_br ..., bb1, bb2 bb1: %0 = load [copy] %globalAddr : $Foo br bb3(%0 : $Foo) bb2: %1 = copy_value %guaranteedFunctionArg : $Foo br bb3(%1 : $Foo): bb3(%2 : @owned $Foo): apply %useFoo(%2) destroy_value %2 : $Foo ``` As a quick proof: Assume the previous rules for guaranteed arguments. Then to promote the load [copy] -> load_borrow and the copy_value to a begin_borrow, we would need to place an end_borrow in bb3. But neither bb1 or bb2 dominates bb3, so we would violate SSA dominance rules. To enable SIL to express this pattern, we introduce a third rule for terminator in ossa that applies only to branch insts. All other branches that obeyed the previous rules (cond_br), still follow the old rule. This is not on purpose, I am just being incremental and changing things as I need to. Specifically, guaranteed arguments whose incoming values are defined by branch instructions now act as a move on guaranteed values. The intuition here is that these arguments are acting as true phis in an SSA sense and thus are just new names for the incoming values. This implies since it is just a new name (not a semantic change) that the guaranteed incoming value's guaranteed scopes should be fused into one scope. The natural way to model this is by treating branch insts as consuming guaranteed values. This then lets us express the example above without using copies as follows: ``` bb0: cond_br ..., bb1, bb2 bb1: %0 = load_borrow %globalAddr : $Foo br bb3(%0 : $Foo) // consumes %0 and acts as %0's end_borrow. bb2: // We need to introduce a new begin_borrow here since function // arguments are required to never be consumed. %1 = begin_borrow %guaranteedFunctionArg : $Foo br bb3(%1 : $Foo) // consumes %1 and acts as %1's end_borrow // %2 continues the guaranteed scope of %0, %1. This time fused with one name. bb3(%2 : @guaranteed $Foo): apply %useFoo(%2) // End the lifetime of %2 (which implicitly ends the lifetime of %0, %1). end_borrow %2 : $Foo ... ``` The main complication for users is that now when attempting to discover the set of implicit users on an owned or guaranteed value caused by their usage as an argument of a borrow introducer like begin_borrow. For those who are unaware, a begin_borrow places an implicit requirement on its parent value that the parent value is alive for the entire part of the CFG where this begin_borrow is live. Previously, one could just look for the end_borrows of the begin_borrow. Now one must additionally look for consuming branch insts. This is because the original value that is being borrowed from must be alive over the entire web of guaranteed values. That is the entire web of guaranteed values act as a liveness requirement on the begin_borrow's operand. The way this is implemented is given a use that we are validating, if the use is a BorrowScopeOperand (1), we see if the borrow scope operand consumes the given guaranteed scope and forwards it into a borrow scope introducer. If so, we add the list of consuming uses of the borrow scope introducer to the worklist to visit and then iterate. In order to avoid working with cycles, for now, the ownership verifier bans liveness requiring uses that have cycles in them. This still allows us to have loop carried guaranteed values. (1) A BorrowScopeOperand is a concept that represents an operand to a SIL instruction that begins a guaranteed scope of some sort. All BorrowScopeOperand are thus at a minimum able to compute a compile time the static region in which they implicitly use their operands. NOTE: We do not require the scope to be represented as a SILValue in the same function. We achieve some nice benefit by introducing this. Specifically: 1. We can optimize the pattern I mentioned above. This is a common pattern in many frameworks that want to return a default object if a computation fails (with the default object usually being some sort of global or static var). This will let us optimize that case when the global is a let global. 2. The SSA Updater can now be used with guaranteed values without needing to introduce extra copies. This will enable predictable mem opts to introduce less copies and for semantic arc opts to optimize the remaining copies that PMO exposes but does not insert itself. rdar://56720519

The main change is that we do not eliminate end_borrows when propagating guaranteed phis. This is because phis now forward guaranteed ownership like owned ownership and since we only eliminate these arguments if all incomign values to the argument is the same (providing dominance).

gottesmm · 2020-02-17T08:30:41Z

@swift-ci test

gottesmm · 2020-02-17T08:30:50Z

@swift-ci test

gottesmm · 2020-02-17T08:31:29Z

@swift-ci test

gottesmm · 2020-02-17T20:59:35Z

I think my commit msg got mangled in a funky way. I need to repost.

gottesmm · 2020-02-17T21:00:27Z

Fixed.

gottesmm · 2020-02-17T21:00:33Z

@swift-ci test

gottesmm · 2020-02-17T21:00:39Z

@swift-ci test

gottesmm · 2020-02-17T21:00:45Z

@swift-ci test

gottesmm · 2020-02-17T21:01:02Z

@swift-ci test

swift-ci · 2020-02-17T21:26:24Z

Build failed
Swift Test OS X Platform
Git Sha - a084c54a01e290d0552ef3ce96a8a6146cb7d446

gottesmm · 2020-02-17T21:33:20Z

@swift-ci source compatibility

gottesmm · 2020-02-17T21:33:28Z

@swift-ci source compatibility

gottesmm · 2020-02-17T21:38:26Z

@swift-ci test source compatibility

gottesmm · 2020-02-18T01:13:36Z

Same failures on Debug source compatibility as on the bots, so it isn't me. See:

15:34:24 ========================================
15:34:24 XFailures:
15:34:24   XFAIL: https://bugs.swift.org/browse/SR-11141, RxSwift, 5.1, 70b8a3, RxCocoa, platform=macOS
15:34:24   XFAIL: https://bugs.swift.org/browse/SR-11248, SwifterSwift, 5.1, ccdc4e, SwifterSwift-watchOS, generic/platform=watchOS
15:34:24   XFAIL: https://bugs.swift.org/browse/SR-11248, SwifterSwift, 4.0, d3c3fd, SwifterSwift-watchOS, generic/platform=watchOS
15:34:24   XFAIL: https://bugs.swift.org/browse/SR-11350, Base64CoderSwiftUI, 5.1, bd103d, Base64CoderSwiftUI, generic/platform=iOS
15:34:24 ========================================
15:34:24 Failures:
15:34:24   FAIL: swift-nio, 4.2, 381fd9, Swift Package
15:34:24   FAIL: swift-nio-extras, 4.2, 0dbd54, Swift Package
15:34:24 ========================================

gottesmm · 2020-02-18T03:03:50Z

Same on the release side. Merging!

atrick · 2020-02-18T03:10:58Z

The description in the PR makes perfect sense. This is how I imagined @guaranteed phis working. I haven't looked very closely at the implementation.

gottesmm requested review from atrick and rjmccall February 17, 2020 05:21

gottesmm added 2 commits February 17, 2020 00:29

gottesmm force-pushed the pr-a905499d41ad40cb3a8a3deb651d2dd2fc3f8ad6 branch from c98c88c to a084c54 Compare February 17, 2020 08:30

gottesmm force-pushed the pr-a905499d41ad40cb3a8a3deb651d2dd2fc3f8ad6 branch from a084c54 to d66d329 Compare February 17, 2020 21:00

gottesmm merged commit 8626cc4 into swiftlang:master Feb 18, 2020

gottesmm deleted the pr-a905499d41ad40cb3a8a3deb651d2dd2fc3f8ad6 branch February 18, 2020 03:04

[ownership] Implement movable guaranteed scopes in ossa. #29875

[ownership] Implement movable guaranteed scopes in ossa. #29875

Uh oh!

Conversation

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

swift-ci commented Feb 17, 2020

Performance: -O

Code size: -O

Performance: -Osize

Code size: -Osize

Performance: -Onone

Code size: -swiftlibs

Uh oh!

swift-ci commented Feb 17, 2020

Uh oh!

swift-ci commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

swift-ci commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 17, 2020

Uh oh!

gottesmm commented Feb 18, 2020

Uh oh!

gottesmm commented Feb 18, 2020

Uh oh!

atrick commented Feb 18, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants