Skip to content

Conversation

gottesmm
Copy link
Contributor

@gottesmm gottesmm commented Mar 5, 2020

Specifically if we have a begin_access [read] or a begin_access [modify] that is
never actually written to. In that case if we can prove that the load [copy] is
completely within the exclusive access region, we will load_borrow. Example:

  %0 = begin_access [read] ...
  %1 = load [copy] %0
  ...
  destroy_value %1
  end_access %0

=>

  %0 = begin_access [read] ...
  %1 = load_borrow %0
  ...
  end_borrow %1
  end_access %0

rdar://60064692

…enclosed in certain kinds of exclusive access scopes.

Specifically if we have a begin_access [read] or a begin_access [modify] that is
never actually written to. In that case if we can prove that the load [copy] is
completely within the exclusive access region, we will load_borrow. Example:

```
  %0 = begin_access [read] ...
  %1 = load [copy] %0
  ...
  destroy_value %1
  end_access %0
```

=>

```
  %0 = begin_access [read] ...
  %1 = load_borrow %0
  ...
  end_borrow %1
  end_access %0
```

rdar://60064692
@gottesmm gottesmm requested a review from jckarter March 5, 2020 04:26
@gottesmm
Copy link
Contributor Author

gottesmm commented Mar 5, 2020

@swift-ci test

@gottesmm
Copy link
Contributor Author

gottesmm commented Mar 5, 2020

@swift-ci benchmark

@gottesmm
Copy link
Contributor Author

gottesmm commented Mar 5, 2020

I am not expecting this to hit that much stuff in the benchmarks necessarily b/c today when you access a var of a class, you have a very small begin_access scope. But this will hit cases where due to @_transparent we have a long begin_access scope like:

func myMethod() {
   let this = self
   func inoutUser(_ x: inout X) { ... }
   inoutUser(&this.myX)
}

@gottesmm
Copy link
Contributor Author

gottesmm commented Mar 5, 2020

If we eventually move a run of semantic arc opts later than inlining, this will be needed as well in general.

@gottesmm
Copy link
Contributor Author

gottesmm commented Mar 5, 2020

@swift-ci test source compatibility

@swift-ci
Copy link
Contributor

swift-ci commented Mar 5, 2020

Performance: -O

Regression OLD NEW DELTA RATIO
ObjectiveCBridgeStubFromNSDateRef 3780 4160 +10.1% 0.91x (?)

Code size: -O

Performance: -Osize

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 Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 16 GB

@swift-ci
Copy link
Contributor

swift-ci commented Mar 5, 2020

Build failed
Swift Test OS X Platform
Git Sha - 0aecebd

@gottesmm
Copy link
Contributor Author

gottesmm commented Mar 5, 2020

@swift-ci test os x platform

@gottesmm gottesmm merged commit c0a866d into swiftlang:master Mar 5, 2020
@gottesmm gottesmm deleted the pr-d0ba712c9532bbdd21033e19354f8fb6b3bb253d branch March 5, 2020 17:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants