Skip to content

[semantic-arc-opts] Use the LiveRange abstraction to find destroys instead of iterating over direct uses so we handle forwarding uses. #29002

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

gottesmm
Copy link
Contributor

@gottesmm gottesmm commented Jan 4, 2020

Previously, we were incorrectly handling these test cases since we weren't
properly finding destroys through forwarding instructions. I fixed that in a
previous commit by changing the code here to only support load [copy] without
forwarding instructions.

In this commit, I change the code to instead use the LiveRange abstraction. The
LiveRange abstraction already knows how to find destroys through forwarding
instructions and has this destroy array already computed for us!

So we get better runtime performance of code (due to the better opt) and better
compile time (since we aren't computing the destroy list twice)!

rdar://58289320

…stead of iterating over direct uses so we handle forwarding uses.

Previously, we were incorrectly handling these test cases since we weren't
properly finding destroys through forwarding instructions. I fixed that in a
previous commit by changing the code here to only support load [copy] without
forwarding instructions.

In this commit, I change the code to instead use the LiveRange abstraction. The
LiveRange abstraction already knows how to find destroys through forwarding
instructions and has this destroy array already computed for us!

So we get better runtime performance of code (due to the better opt) and better
compile time (since we aren't computing the destroy list twice)!

rdar://58289320
@gottesmm
Copy link
Contributor Author

gottesmm commented Jan 4, 2020

@swift-ci test

@gottesmm
Copy link
Contributor Author

gottesmm commented Jan 4, 2020

@swift-ci benchmark

@swift-ci
Copy link
Contributor

swift-ci commented Jan 4, 2020

Build failed
Swift Test OS X Platform
Git Sha - 2b09547

@gottesmm
Copy link
Contributor Author

gottesmm commented Jan 4, 2020

@swift-ci test os x platform

@swift-ci
Copy link
Contributor

swift-ci commented Jan 4, 2020

Performance: -O

Improvement OLD NEW DELTA RATIO
FlattenListFlatMap 4876 4440 -8.9% 1.10x (?)

Code size: -O

Performance: -Osize

Improvement OLD NEW DELTA RATIO
FlattenListLoop 2756 2572 -6.7% 1.07x (?)

Code size: -Osize

Performance: -Onone

Improvement OLD NEW DELTA RATIO
DataAppendDataSmallToSmall 3200 2800 -12.5% 1.14x (?)

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

@gottesmm
Copy link
Contributor Author

gottesmm commented Jan 4, 2020

No regressions, good. I figured we wouldn't see much since we hadn't hit this bug yet.

@swift-ci
Copy link
Contributor

swift-ci commented Jan 4, 2020

Build failed
Swift Test Linux Platform
Git Sha - 2b09547

@gottesmm
Copy link
Contributor Author

gottesmm commented Jan 4, 2020

@swift-ci test linux platform

@gottesmm
Copy link
Contributor Author

gottesmm commented Jan 4, 2020

@swift-ci test windows platform

@gottesmm gottesmm merged commit ad79c2b into swiftlang:master Jan 4, 2020
@gottesmm gottesmm deleted the pr-ff454301beb141a7a342948592e5c4436ec3b1e2 branch January 4, 2020 03:46
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