Optimizer: re-implement the RedundantLoadElimination pass in Swift #67395
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci test |
|
@swift-ci benchmark |
eeckstein
force-pushed
the
redundant-load-elimination
branch
from
2f6415f to
b9fb63b
Compare
|
@swift-ci test |
|
@swift-ci benchmark |
…tore [assign]` So far we unconditionally treated `store [assign]` to have side effects because it destructs the old value. But we can do better by checking if the address in question actually can escape to a destructor.
…struction for a `yield` access base A begin_apply can yield multiple addresses. We need to store the result of the apply in order to distinguish between two AccessBases with different results from the same begin_apply.
…e equivalent This is possible now because projection path now models index-addressing correctly.
…n` when getting the root of a reference
To make it available in other optimizations as well. Also, a few problems: * Use destructre instructions when in OSSA * Don't split the store if it's nominal type has unreferenceable stoarge * rename it to `trySplit` because it's not guaranteed to work Also, add the counterpart for load instructions: `LoadInst.trySplit()`
The new implementation has several benefits compared to the old C++ implementation: * It is significantly simpler. It optimizes each load separately instead of all at once with bit-field based dataflow. * It's using alias analysis more accurately which enables more loads to be optimized * It avoids inserting additional copies in OSSA The algorithm is a data flow analysis which starts at the original load and searches for preceding stores or loads by following the control flow in backward direction. The preceding stores and loads provide the "available values" with which the original load can be replaced.
eeckstein
force-pushed
the
redundant-load-elimination
branch
from
b9fb63b to
29246fd
Compare
|
@swift-ci test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The new implementation has several benefits compared to the old C++ implementation:
The algorithm is a data flow analysis which starts at the original load and searches for preceding stores or loads by following the control flow in backward direction.
The preceding stores and loads provide the "available values" with which the original load can be replaced.
This is the counterpart to the new implementation of dead-store elimination (#67122)