-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[tmp] Access scope handling #31208
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
[tmp] Access scope handling #31208
Conversation
Adds support for projecting through begin_access instructions.
After low-level SSA passes, often the only use of an object will be dead stores. At some point after dead store elimination, dead object elimination is useful. The dead code elimination pass is fast and removes some remaining uses of the object after DSE (such as dead access instructions).
Simple check for the following pattern: x = begin_access end_access x
RLE can ignore end_access, set_deallocating, dealloc_ref, begin_access, and strong_release instructions. DSE can ignore end_access, set_deallocating, begin_access, and sometimes strong_Release.
This means that "LastRelease" can be tracked through multiple basic blocks.
@swift-ci please benchmark |
I should elaborate: I want to benchmark #31136 in isolation but, the performance improvements I'm looking for there are only possible with changes from other PRs. I've benchmarked all the live value analysis changes in #31078 so, I'm running the benchmarks on the non-alias analysis changes here. That way I can compare to two benchmark results and see if #31136 has a significant performance improvement. |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibsHow to read the dataThe 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 Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
A rough summary of the difference between the performance improvements with optimizations: the regressions are similar. There are five or six added regressions in both PRs (all 10-20% slower). There are about 50% more tests that had improvements (big and small) with the alias analysis patch. Given this, I think that the alias analysis patch is sufficiently beneficial. |
Don't merge this PR. This PR is to run the benchmarks and compare to #31078.