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.
This fixes:
* An issue where the diagnostic messages were leaked
* Diagnose at correct position inside the regex literal
To do this:
* Introduce 'Parse' SwiftCompiler module that is a bridging layer
between '_CompilerRegexParser' and C++ libParse
* Move libswiftParseRegexLiteral and libswiftLexRegexLiteral to 'Parse'
Also this change makes 'SwiftCompilerSources/Package.swift' be configured
by CMake so it can actually be built with 'swift-build'.
rdar://92187284
The ComputeEffects pass derives escape information for function arguments and adds those effects in the function.
This needs a lot of changes in check-lines in the tests, because the effects are printed in SIL
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.
The ComputeEffects pass derives escape information for function arguments and adds those effects in the function.
This needs a lot of changes in check-lines in the tests, because the effects are printed in SIL
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.
Currently, SwiftCompilerSources' inclusion of the regex parser depends on CMake flag `SWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING`. However, in some scenarios we want to build the regex parser as part of the compiler _without_ building the runtime modules. This patch makes building the regex parser the default regardless of `SWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING`. Only when the build environment is missing the string processing repo, we skip building the regex parser by setting `SWIFT_BUILD_REGEX_PARSER_IN_COMPILER` to false.
* C++: add a function `getDestructors(SILType type, bool isExactType)’: if the type is a final class or `isExactType` is true, then return the one and only destructor of that class.
* swift: add `getDestructor(ofExactType type: Type)` and `getIncompleteCallees`
* swift: remove `getDestructor` from the PassContext. The API of the `calleeAnalysis` can be used instead.
As the _MatchingEngine module no longer contains the matching engine, this patch renames this module to describe its role more accurately. Because this module primarily contains the AST and the regex parsing logic, I propose we rename it to "_RegexParser".
Also renames the ExperimentalRegex module in SwiftCompilerSources to _RegexParser for consistency. This would prevent errors if sources in _RegexParser used qualified lookup with the module name.
The release-devirtualizer must not run on the same alloc_ref twice.
This is a very rare case, but if it happens it's a very bad thing, because it results in a double-free crash.
The fix is to detect that a dealloc_ref instruction (although it isn't "releasing"), does a memory deallocation.
Found by doing some unrelated experiments.
Store a list of argument effects in a function, which specify if and how arguments escape.
Such effects can be specified in the Swift source code (for details see docs/ReferenceGuides/UnderscoredAttributes.md) or derived in an optimization pass.
For details see the documentation in SwiftCompilerSources/Sources/SIL/Effects.swift.
The `SmallProjectionPath` represents a path of value or address projections.
It’s used for defining argument effects for functions and for the new escape analysis.
The `run-unit-tests` is a "pseudo" pass which is invoked from sil-opt and runs all the unit tests, implemented in Swift.
This is done from the `swift-unit-tests.sil` lit test.
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).
* add `BasicBlockSet`
* add `BasicBlockWorklist`
* add `BasicBlockRange`, which defines a range of blocks from a common dominating “begin” block to a set of “end” blocks.
* add `InstructionRange`, which is similar to `BasicBlockRange`, just on instruction level. It can be used for value lifetime analysis.
* rename `StackList` -> `Stack` and move it to `Optimizer/DataStructures`
* rename `PassContext.passContext` to `PassContext._bridged`
* add notify-functions to PassContext
Improve block/instruction lists and similar collections
* pretty print collections in the form “[a, b, c]”
* also do this for lazy sequences
* define a custom Mirror
* in a collection, only print the name of blocks, functions and globals (instead of the full object)
* replace `BasicBlock.reverseInstructions` with `BasicBlock.instructions.reversed()` - in an efficient way
