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
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.
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.
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
We did this for @in => @owned for all parameters before enabling +0. We decided
to defer this work to after +0 was turned back on.
This also fixes the array_contentof_opt test without making append(contentOf: )
take the container at +1.
rdar://38152291
The conformance existing isn't enough to be sure the cast will succeed,
there may be dynamic information, so we just assume they're always
dynamic and always "MaySucceed".
Fixes rdar://problem/38694450.
Will be used to verify that withoutActuallyEscaping's block does not
escape the closure.
``%escaping = is_escaping_closure %closure`` tests the reference count. If the
closure is not uniquely referenced it prints out and error message and
returns true. Otherwise, it returns false. The returned result can be
used with a ``cond_fail %escaping`` instruction to abort the program.
rdar://35525730
We already do this for @in parameters. I think it was just never implemented for
@in_guaranteed. The reason I am doing this now is that a bunch of test cases
that tested @in -> trivial. By doing this I get the @in_guaranteed -> trivial
implying those test cases do not need to be updated.
Important Note: We have bad test cases for resilience when dealing with generic specializer. Also add correct test cases + change existing ones
Note2: We only support this for trivial in_guaranteed types
This patch both makes debug variable information it optional on
alloc_stack and alloc_box instructions, and forced variable
information on debug_value and debug_value_addr instructions. The
change of the interface uncovered a plethora of bugs in SILGen,
SILTransform, and IRGen's LoadableByAddress pass.
Most importantly this fixes the previously commented part of the
DebugInfo/local-vars.swift.gyb testcase.
rdar://problem/37720555
The devirtualizer performs two optimizations:
- If a value is known to have an exact class type, ie it is the result of an alloc_ref, we can devirtualize calls of *non-final* methods, because we know we’re calling that specific method and not an override.
- If a method is known to be “effectively final” (it is not open, and there are no overrides inside the module) we can devirtualize it.
However the second optimization needs to be disabled if a function is inlinable (F->getResilienceExpansion() == ResilienceExpansion::Minimal).
