It is valid to leak a value on paths into dead-end regions.
Specifically, it is valid to leak an `alloc_box`. Thus, "final
releases" in dead-end regions may not destroy the box and consequently
may not release its contents. Therefore it's invalid to lower such final
releases to `dealloc_stack`s, let alone `destroy_addr`s. The in-general
invalidity of that transformation results in miscompiling whenever a box
is leaked and its projected address is used after such final releases.
Fix this by not treating final releases as boundary markers of the
`alloc_box` and not lowering them to `destroy_addr`s and
`dealloc_stack`s.
rdar://158149082
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
I am doing this since region based isolation hit the same issue that the move
checker did. So it makes sense to refactor the functionality into its own pass
and move it into a helper pass that runs before both.
It is very conservative and only stubifies functions that the specialization
passes explicitly mark as this being ok to be done to.
Adding `move_value [lexical]` and `begin_borrow [lexical]` should happen
all the time at this point. Remove the ability to omit these
instructions and update the corresponding tests.
This is an improvement of #67031 which avoids deleting the closure function
body during AllocBoxToStack, which still breaks pass invariants by modifying
functions other than the currently-analyzed function. As a function pass,
AllocBoxToStack also doesn't really know with certainty whether the original
closure function is unused after stack promotion or not. We still want to
eliminate the original when it may contain invalid SIL for move-only values
that rely on the escape analysis for correct semantics, so rather than mark the
original function to be *ignored* during move-only checking, mark it to be
*deleted* by move-only checking if the function is in fact unused at that
point.
If the marked function is still used, we let it pass through move-only
checking normally, which may cause redundant diagnostics but is the right
thing to do since code is still potentially using the closure with escaping
semantics. We should rearrange things to make this situation impossible in
the future.
rdar://110675352
We can't remove the functions at this point in case they might have other function
passes enqueued to run on them, but we can at least remove the function contents
that are now unnecessary. We need to do this in cases when move-only types are
involved, since the semantics of the move checker rely on unescaped captures being
promoted before the pass runs, and we leave behind invalid SIL in the unpromoted code.
rdar://110675352
Specifically, we already have the appropriate semantics for arguments captured
by escaping closures but in certain cases allocbox to stack is able to prove
that the closure doesn’t actually escape. This results in the capture being
converted into a non-escaping SIL form. This then causes the move checker to
emit the wrong kind of error.
The solution is to create an early allocbox to stack that doesn’t promote move
only types in boxes from heap -> stack if it is captured by an escaping closure
but does everything else normally. Then once the move checking is completed, we
run alloc box to stack an additional time to ensure that we keep the guarantee
that heap -> stack is performed in those cases.
rdar://108905586
The old syntax was
@opened("UUID") constraintType
Where constraintType was the right hand side of a conformance requirement.
This would always create an archetype where the interface type was `Self`,
so it couldn't cope with member types of opened existential types.
Member types of opened existential types is now a thing with SE-0309, so
this lack of support prevented writing SIL test cases using this feature.
The new syntax is
@opened("UUID", constraintType) interfaceType
The interfaceType is a type parameter rooted in an implicit `Self`
generic parameter, which is understood to be the underlying type of the
existential.
Fixes rdar://problem/93771238.
In case of a borrowed `alloc_box`, the optimization didn't look through the `begin_borrow` when calculating the final release of the box.
This resulted in inserting the destroy of the inserted `alloc_stack` too early.
rdar://97087762
Introduce a new instruction `dealloc_stack_ref ` and remove the `stack` flag from `dealloc_ref`.
The `dealloc_ref [stack]` was confusing, because all it does is to mark the deallocation of the stack space for a stack promoted object.
We should be able to accept mark_uninitialized in this position. The assert was
just being careful so that the codegen that we accept here is constricted
explicitly.
rdar://86535218
In preparation for changing the default, explicitly specify the behavior
of all tests that are affected by the choice of behavior for lexical
lifetimes and copy-propagation.
The effect of passing -enable-copy-propagation is both to enable the
CopyPropagation pass to shorten object lifetimes and also to enable
lexical lifetimes to ensure that object lifetimes aren't shortened while
a variable is still in scope and used.
Add a new flag, -enable-lexical-borrow-scopes=true to override
-enable-copy-propagation's effect (setting it to ::ExperimentalLate) on
SILOptions::LexicalLifetimes that sets it to ::Early even in the face of
-enable-copy-propagation. The old flag -disable-lexical-lifetimes is
renamed to -enable-lexical-borrow-scopes=false but continues to set that
option to ::Off even when -enable-copy-propagation is passed.
This patch replace all in-memory objects of DebugValueAddrInst with
DebugValueInst + op_deref, and duplicates logics that handles
DebugValueAddrInst with the latter. All related check in the tests
have been updated as well.
Note that this patch neither remove the DebugValueAddrInst class nor
remove `debug_value_addr` syntax in the test inputs.
For those who are unfamiliar, alloc-box-to-stack while generally not
interprocedural, will look one level into the callgraph to see if a
partial_apply that captures a box really needs to capture the box due to an
escape. If not, allocbox-to-stack clones the closure with the address inside the
box being passed instead of the box itself. This can then allow us to promote
the box from the heap to the stack.
What went wrong here is that in OSSA, this promoted param cloner drops
copy_value, destroy_value, and project_box on the given box. Both the copy_value
and destroy_value cases correctly looked through copy_values, but when porting,
the author forgot to handle project_box as well. This then caused the cloner to
assert since:
1. The project_box in the original function had a copy_value operand.
2. When we visited that copy_value, we saw it was for the box, so we dropped the
copy_value and did not add it to the cloner's Value -> op(Value) map.
3. Then when the cloner tried to create op(project_box), it tries to lookup the
value associated with the copy_value that is the project_box's operand... but we
don't have any such value due to (2). =><=.
The test change exercises this code path by adding a (project_box (copy_value))
to one of the allocbox to stack tests.
NOTE: I also added a partial_apply [guaranteed] test.
Whats interesting about these is that we only ever perform allocbox_to_stack if
we know that we are going to eliminate the allocbox completely. So if we break
dominance among some uses of the alloc box or insert destroy_value when we are
in non-ossa... it doesn't matter since we will eliminate the box and these uses
before the pass is done running.
This will harmless on the surface is an instance of the compiler being in a
"fixed point of correctness". This occurance is when the compiler implementation
is incorrect but the incorrectness is being hidden in the final output. If the
output of the compiler changes or the code in question is changed, new bugs can
be introduced due to the lack of preserving of standard invariants like
dominance.
I also added an additional helper: SILBuilder::insertAfter(SILValue). This
builds on Erik's commit that gave us insert(SILInstruction *). I wanted this
functionality, but additionally I wanted to make it so that if I had an
argument, I got back the first instruction in the block. So it was natural to
extend this to values.
* Don't always give shared linkage to spl functions
private functions on specialization were being given shared linkage.
Use swift::getSpecializeLinkage to correctly get the linkage for the
specialized function based on the linkage of the original function.
* Extend AllocBoxToStack to handle apply
AllocBoxToStack analyzes the uses of boxes and promotes them to stack if
it is safe to do so. Currently the analysis is limited to only a few known
users including partial_apply.
With this change, the pass also analyzes apply users, where the callee
is a local private function.
The analysis is recursive and bound by a threshold.
Fixes rdar://59070139
Even if a destroy_addr of a trivial type is a no-op, we must not end up with using such a value after a destroy_addr.
The fix is to also handle aggregate fields of trivial types in MemoryLifetime.
rdar://problem/55125020
Specifically, we were preferring the always correct ownership kind specified by
the FunctionType and ignoring what we parsed from the argument. This PR changes
ossa to give a nice error when this is detected and fixes the places where this
tests were written incorrectly.
I also removed the -verify-sil-ownership flag in favor of a disable flag
-disable-sil-ownership-verifier. I used this on only two tests that still need
work to get them to pass with ownership, but whose problems are well understood,
small corner cases. I am going to fix them in follow on commits. I detail them
below:
1. SILOptimizer/definite_init_inout_super_init.swift. This is a test case where
DI is supposed to error. The only problem is that we crash before we error since
the code emitting by SILGen to trigger this error does not pass ownership
invariants. I have spoken with JoeG about this and he suggested that I fix this
earlier in the compiler. Since we do not run the ownership verifier without
asserts enabled, this should not affect compiler users. Given that it has
triggered DI errors previously I think it is safe to disable ownership here.
2. PrintAsObjC/extensions.swift. In this case, the signature generated by type
lowering for one of the thunks here uses an unsafe +0 return value instead of
doing an autorelease return. The ownership checker rightly flags this leak. This
is going to require either an AST level change or a change to TypeLowering. I
think it is safe to turn this off since it is such a corner case that it was
found by a test that has nothing to do with it.
rdar://43398898
I have been meaning to do this change for a minute, but kept on putting it off.
This describes what is actually happening and is a better name for the option.
Instead of some special treatment of unreachable blocks, model unreachable as implicitly deallocating all alive stack locations at that point.
This requires an additional forward-dataflow pass. But it now correctly models the problem and fixes a compiler crash.
rdar://problem/47402694
In a previous commit, I banned in the verifier any SILValue from producing
ValueOwnershipKind::Any in preparation for this.
This change arises out of discussions in between John, Andy, and I around
ValueOwnershipKind::Trivial. The specific realization was that this ownership
kind was an unnecessary conflation of the a type system idea (triviality) with
an ownership idea (@any, an ownership kind that is compatible with any other
ownership kind at value merge points and can only create). This caused the
ownership model to have to contort to handle the non-payloaded or trivial cases
of non-trivial enums. This is unnecessary if we just eliminate the any case and
in the verifier separately verify that trivial => @any (notice that we do not
verify that @any => trivial).
NOTE: This is technically an NFC intended change since I am just replacing
Trivial with Any. That is why if you look at the tests you will see that I
actually did not need to update anything except removing some @trivial ownership
since @any ownership is represented without writing @any in the parsed sil.
rdar://46294760
introduce a common superclass, SILNode.
This is in preparation for allowing instructions to have multiple
results. It is also a somewhat more elegant representation for
instructions that have zero results. Instructions that are known
to have exactly one result inherit from a class, SingleValueInstruction,
that subclasses both ValueBase and SILInstruction. Some care must be
taken when working with SILNode pointers and testing for equality;
please see the comment on SILNode for more information.
A number of SIL passes needed to be updated in order to handle this
new distinction between SIL values and SIL instructions.
Note that the SIL parser is now stricter about not trying to assign
a result value from an instruction (like 'return' or 'strong_retain')
that does not produce any.
