While I was using the new AccessUtils for a new optimization pass I discovered some areas for improvements. Also I found some bugs.
Changes:
* AccessBase: remove the unhealthy redundancy between `kind` and `baseAddress` types. Now AccessBase is single enum with the relevant base objects/addresses as payloads.
* AccessBase: for `global`, store the `GlobalValue` and not a `global_address` instruction, which is more accurate (because there can be multiple `global_addr`s for a single global variable)
* AccessBase: drop the support for function argument "pointers". The `pointer` is now always a `pointer_to_address` instruction. This also simplifies `PointerIdentification`: either it finds a matching `address_to_pointer` or it bails.
* AccessBase: improve `func isDistinct(from:)`. There are more possibilities to prove that two access bases do not alias.
* AccessBase: replace `var isUniquelyIdentified` with `var hasKnownStorageKind` which is more useful for aliasing checking.
* AccessPath: fix `func isDistinct(from:)`. `SmallProjectionPath.matches` is the wrong way to check if two expression paths may overlap. Instead use the new `SmallProjectionPath.mayOverlap`.
* AccessStoragePathWalker: rename `getAccessStorage` -> `visitAccessStorageRoots` and let it return false if it's not a class/reference AccessBase.
* add tests for `AccessPath.isDistinct(from:)`
* "merge" the `Path` and `State` in WalkUtils into a single `WalkingPath`. This makes it simpler for clients to configure a path and additional state variables. EscapeInfo now defines `EscapePath` which includes the projection path and EscapeInfo's specific state variables.
* Make the `WalkerCache` part of the WalkUtils, so that not all clients have to re-implement it.
* Rename `walkDownResults` -> `walkDownAllResults` and `walkUpOperands` -> `walkUpAllOperands` and make these functions client configurable.
`EscapeInfo` now conforms to the generic protocols defined in `WalkUtils`.
This simplifies the implementation a bit, since trivial instructions are handled
by `WalkUtils` and `EscapeInfo` only has to handle a subset of instructions
inherent to escape information.
Passes using `EscapeInfo` are updated accordingly to become visitors that
customize the `EscapeInfo` walk.
Introduces a set of protocols useful to perform def-use and use-def
traversals to find uses and definitions of values.
This logic was originally baked into `EscapeInfo` directly.
Here we extract it into general utilities, namely:
- `ValueDefUseWalker`: visit uses of a value walking down value-value projections/constructions.
- `AddressDefUseWalker`: visit uses of an address walking down addr-addr projections/constructions.
- `ValueUseDefWalker`: visit definitions of a value walking up value-value projections/constructions.
- `AddressUseDefWalker`: visit definitions of an address walking up addr-addr projections/constructions.
These utilities can then be used in other passes or to create
new utilities by composing them. For example to find a definition
passing through both address projections and value extractions,
it's enough to implement a visitor conforming to both
`AddressUseDefWalker` and `ValueUseDefWalker`.
Utilities to make a value available to be used in another basic block.
Inserts required `copy_value` and `destroy_value` operations in case the destination block is in a different control region than the value.
For example, if the destination block is in a loop while the value is not in that loop, the value has to be copied for each loop iteration.
Add a flag `analyzeAddresses` for distinguishing address vs value escape analysis. This is simpler than handling that in the visitUse/visitDef closures.
Also, fix a related bug, which let an address, which is escaping to a function, get unnoticed.
It’s a replacement for the old `EscapeAnalysis`, implemented in Swift (instead of C++) and with a much simple design and implementation.
While the old EscapeAnalysis builds a connection graph, the new EscapeInfo just performs a simple def-use and use-def walk in the SIL.
The EscapeInfo does not need to analyze the whole function (like the EscapeAnalysis does), but just the relevant value which is inspected. Therefore EscapeInfo is not an `Analysis` which caches its result across optimization passes - it’s not needed.
It’s a replacement for the old `EscapeAnalysis`, implemented in Swift (instead of C++) and with a much simple design and implementation.
While the old EscapeAnalysis builds a connection graph, the new EscapeInfo just performs a simple def-use and use-def walk in the SIL.
The EscapeInfo does not need to analyze the whole function (like the EscapeAnalysis does), but just the relevant value which is inspected. Therefore EscapeInfo is not an `Analysis` which caches its result across optimization passes - it’s not needed.
For inserting new instruction after another instruction. This is especially interesting if the insertion point is a terminator.
In this case, the new instruction(s) are inserted in the successor block(s).
