I am also going to use this to implement Guaranteed -> Owned in its own file.
The exploding of the other parts of function-sig-opts will happen later.
rdar://38196046
This ensures that we perform analysis and transformation in the same order. This
is the last missing piece before I can split function signature opts (a task for
another time).
rdar://38196046
This functionality is really specific to FunctionSignatureOpts. It really
doesn't make sense to have it as a utils until it becomes more general or we
need it in multiple places.
NFC.
rdar://38196046
I am going to be adding logic here to enable apple/swift#1550 to be completed.
The rename makes sense due to precedent from LLVM's codegen prepare and also
since I am going to be expanding what the pass is doing beyond just "cleaning
up". It is really a grab bag pass for performing simple transformations that we
do not want to pollute IRGen's logic with.
https://github.com/apple/swift/pull/15502
rdar://39335800
Make this a generic analysis so that it can be used to analyze any
kind of function effect.
FunctionSideEffect becomes a trivial specialization of the analysis.
The immediate need for this is to introduce an new
AccessedStorageAnalysis, although I foresee it as a generally very
useful utility. This way, new kinds of function effects can be
computed without adding any complexity or compile time to
FunctionSideEffects. We have the flexibility of computing different
kinds of function effects at different points in the pipeline.
In the case of AccessedStorageAnalysis, it will compute both
FunctionSideEffects and FunctionAccessedStorage in the same pass by
implementing a simple wrapper on top of FunctionEffects.
This cleanup reflects my feeling that nested classes make the code
extremely unreadable unless they are very small and either private or
only used directly via its parent class. It's easier to see how these
classes compose with a flat type system.
In addition to enabling new kinds of function effects analyses, I
think this makes the implementation of side effect analysis easier to
understand by separating concerns.
Otherwise, when we mangle a signature of bridged/not_bridged arguments
we can see the state from the previous match of another instruction.
SR-7426
rdar://39414272
This is a property of an instruction and should be a member
function of `SILInstruction` and not a free function in
`DebugUtils`. Discussed with Adrian.
Fixes <rdar://problem/39209102> [SR-7354]: Swift 4.1 Regression: EXC_BAD_ACCESS for Optimized Builds in Xcode 9.3
Commentary:
The underlying problem is that CopyForwarding is an inherently
dangerous pass by design that has been waiting for the SIL
representation to evolve to the point where it can be rewritten.
The regressions was caused by PredictableMemOps failing to preserve
normal patterns of ownership. When it forwards loads, it implicitly
extends the lifetime of stored value
store %val to %addr
...
retain %val
...
destroy_addr %addr
CopyForwarding already tried to detect such violations of ownership
rules and normally bypasses destroy hoisting in those cases. In this
case, it fails to detect the problem because PredictableMemOps has
already erased the load, so there's no evidence of the value's
lifetime being extended.
It might have been nice if PredictableMemOps had transformed the
retain %val into a retain %addr. However, for the immediate fix, we
don't want to change any existing behavior other than suppressing
optimization. In the long term, CopyForwarding does not really make
sense without SemanticSIL+SILOwnership and should be totally rewritten
and greatly simplified at that point.
I am getting rid of FunctionSignatureOptUtils. It is only used by
FunctionSignatureOpts, so it should either be a local utility file whose header
lives in ./lib or integrated into FunctionSignatureOpts. Beyond this utility
function (which seems like a generally useful thing that should be in
DebugUtils), the only other thing left in FunctionSignatureOptUtils is part of
the heuristic of FunctionSignatureOpts. It should really be in that file.
rdar://38196046
The two methods on FunctionSignatureTransform in question:
createOptimizedSILFunctionName()
createOptimizedSILFunctionType()
are pure computation on the transform descriptor on the
FunctionSignatureTransform. So there really isn't a reason not to make it a
getter method on FunctionSignatureTransformDescriptor. This helps me to thin out
FunctionSignatureTransform even further in prepration for splitting it.
This is something that has been talked about for some time. By splitting up
function signature optimization into several smaller "transforms" that can be
composed, we are able to test each transform individually as well as make it
easier to add more optimizations. Hopefully, other function signature
optimizations we currently perform with separate passes can be combined into
this framework.
NFC.
We never push_back additional such items onto the descriptor lists once the
transform is constructed. We do on the other hand, potentially modify those
items in the vector. That suggests that this property is better represented by
the "simpler" MutableArrayRef.
