Provides a list of instructions, which reference a function.
A function "use" is an instruction in another (or the same) function which references the function.
In most cases those are `function_ref` instructions, but can also be e.g. `keypath` instructions.
'FunctionUses' performs an analysis of all functions in the module and collects instructions which reference other functions.
This utility can be used to do inter-procedural caller-analysis.
* add `DynamicFunctionRefInst` and `PreviousDynamicFunctionRefInst`
* add a common base class to all function-referencing instructions: `FunctionRefBaseInst`
* add `KeyPathInst`
* add `IndexAddrInst.base` and `IndexAddrInst.index` getters
* add `Instruction.visitReferencedFunctions` to visit all functions which are referenced by an instruction
To add a module pass in `Passes.def` use the new `SWIFT_MODULE_PASS` macro.
On the swift side, create a `ModulePass`.
It’s run function receives a `ModulePassContext`, which provides access to all functions of a module.
But it doesn't provide any APIs to modify functions.
In order to modify a function, a module pass must use `ModulePassContext.transform(function:)`.
It fixes the default reflection for bridged random access collections, which usually have a `bridged` stored property.
Conforming to this protocol displays the "real" children of a bridged random access collection and not just `bridged`.
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:)`
`sed` is not available on all platforms, we cannot depend on that to
rewrite the module map. As a temporary stop gap, write the file
statically and generate it at build time. Eventually, this could be
replaced with a tool or CMake based text processing to generate the
content. This repairs part of the build for Windows with bootstrapping.
The bootstrapping stages were missing dependencies on the Concurrency
and Swift 5.6 backdeployment compatibility libraries resulting in
failing builds.
When using a unified LLVM + Swift build (using `LLVM_EXTERNAL_PROJECTS=swift`),
`CMAKE_SOURCE_DIR` is `llvm-project/llvm`, and appending `include/swift` to that directory doesn’t result in the directory that contains Swift’s header files.
Instead, look up the header files relative to `CMAKE_CURRENT_SOURCE_DIR`.
* "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.
When using a unified LLVM + Swift build (using `LLVM_EXTERNAL_PROJECTS=swift`), swift is installed into `build_dir/tools/swift`. Thus, we also need to find the generated headers inside the `tools/swift/include` directory and not at the top-level `build_dir/include` directory.
This also removes `BridgedDiagnosticArgumentKind` in favor of `swift::DiagnosticArgumentKind`, bringing us one step closer to bridging the entire diagnostic engine via C++ interop.
rdar://83361087
These sets are _much_ more efficient than `Set<Value>` and `Set<Instruction>` because they bridge to the efficient `NodeSet`.
Insertions/deletions are just bit operations.
It's used to implement `InstructionSet` and `ValueSet`: sets of SILValues and SILInstructions.
Just like `BasicBlockSet` for basic blocks, the set is implemented by setting bits directly in SILNode.
This is super efficient because insertion and deletion to/from the set are basic bit operations.
The cost is an additional word in SILNode. But this is basically negligible: it just adds ~0.7% of memory used for SILInstructions.
In my experiments, I didn't see any relevant changes in memory consumption or compile time.
