Such destroys mark the lifetime end of their operands along their
availability boundary. They are currently inserted in this test case
by the ClosureLifetimeFixup pass, but in the fullness of time they will
be present for every value which is not explicitly destroyed (that's
what complete OSSA lifetimes is mostly about).
Currently, such destroys are diagnosed by DiagnoseUnreachable. Fix the
diagnostic pass not to diagnose these valid instructions.
rdar://137960229
Currently, InstructionVisitor is only used during the serialization pass,
that comes after a pass that checks if instructions are serializable. This
causes inconsistencies as some types bypass the first pass but are processed
in the second, leading to assert fails.
This PR uses InstructionVisitor in the first pass to be exhaustive and to
be consistent with the coverage in the second pass. The downside is the visitor
is SILCloner, which introduces overhead of cloning and discarding insts per pass
-- a potential area for future refactoring.
Resolves rdar://130788545.
* fix a false error if a derived class has different generic parameters than its base class
* fix a similar problem if a non-generic class derives from a generic class
* fix a compiler crash for calling a class method on a class metatype
rdar://137692055
PredictableMemOpt only runs with OSSA. The recent refactoring did not
preserve non-OSSA conditions because it adds complexity. This commit
just makes it official.
In the near future, this pass will be replaced by an OSSA-only pass
anyway, so this brings us one small step closer to that.
Just to make it a little quicker to debug/get this information when debugging
the pass. I have been wanting this and just hadn't gotten around to adding it.
It just centralizes the last piece of information that one wants to reach for
when debugging.
When its operand has coroutine kind `yield_once_2`, a `begin_apply`
instruction produces an additional value representing the storage
allocated by the callee. This storage must be deallocated by a
`dealloc_stack` on every path out of the function. Like any other stack
allocation, it must obey stack discipline.
The optimization replaces a `load [copy]` with a `load_borrow` if possible.
```
%1 = load [copy] %0
// no writes to %0
destroy_value %1
```
->
```
%1 = load_borrow %0
// no writes to %0
end_borrow %1
```
The new implementation uses alias-analysis (instead of a simple def-use walk), which is much more powerful.
rdar://115315849
The reason that I am modifying this error is that in situations like the
following one can have a Sendable type that triggers this error since the box
containing the value is non-Sendable.
```
func methodConsuming(x: consuming SendableKlass) async throws {
try await withThrowingTaskGroup(of: Void.self) { group in
group.addTask { // expected-tns-warning {{passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution of the closure}}
useValue(x) // expected-tns-note {{closure captures reference to mutable var 'x' which is accessible to code in the current task}}
}
try await group.waitForAll()
}
}
```
rdar://133813644
(cherry picked from commit 36c2b3cc1330c07dcf9715f8ae88d31f9dba58c4)
Pre-specialization of `Array._endMutation` (for AnyObject) prevents inlining this function and that results in sub-optimal code.
This function is basically a no-op. So it should be inlined.
Unfortunately we cannot remove the specialize-attributes anymore because the pre-specialized function(s) are now part of the stdlib's ABI.
Therefore make an exception for `Array._endMutation` in the generic specializer.
In Embedded Swift, witness method lookup is done from specialized witness tables.
For this to work, the type of witness_method must be specialized as well.
Otherwise the method call would be done with wrong parameter conventions (indirect instead of direct).
In Embedded Swift, witness method lookup is done from specialized witness tables.
For this to work, the type of witness_method must be specialized as well.
Otherwise the method call would be done with wrong parameter conventions (indirect instead of direct).
This requires two major changes.
The first is that we need to teach SILGen that the isolation of an initializer
is essentially dynamic (as far as SILGen is concerned) --- that it needs to emit
code in order to get the isolation reference. To make this work, I needed to
refactor how we store the expected executor of a function so that it's not
always a constant value; instead, we'll need to emit code that DI will lower
properly. Fortunately, I can largely build on top of the work that Doug previously
did to support #isolation in these functions. The SIL we emit here around delegating
initializer calls is not ideal --- the breadcrumb hop ends up jumping to the
generic executor, and then DI actually emits the hop to the actor. This is a little
silly, but it's hard to eliminate without special-casing the self-rebinding, which
honestly we should consider rather than the weirdly global handling of that in
SILGen today. The optimizer should eliminate this hop pretty reliably, at least.
The second is that we need to teach DI to handle the pattern of code we get in
delegating initializers, where the builtin actually has to be passed the self var
rather than a class reference. This is because we don't *have* a class reference
that's consistently correct in these cases. This ended up being a fairly
straightforward generalization.
I also taught the hop_to_executor optimizer to skip over the initialization of
the default-actor header; there are a lot of simple cases where we still do emit
the prologue generic-executor hop, but at least the most trivial case is handled.
To do this better, we'd need to teach this bit of the optimizer that the properties
of self can be stored to in an initializer prior to the object having escaped, and
we don't have that information easily at hand, I think.
Fixes rdar://87485045.
This fixes a logic error that will only be exposed by the additional
functionality that motivated the cleanup. When the additional
functionality is checked in, it will contain a unit test for this fix.
This bug was introduced in:
commit 755a146730 (public/predmem_rewrite)
Author: Andrew Trick <atrick@apple.com>
Date: Fri Sep 27 22:18:29 2024
[NFC] rewrite PredictableMemOpts dead allocation elimination
For now this will only be used for HopToMainActorIfNeeded thunks. I am creating
this now since in the past there has only been one option for creating
thunks... to create the thunk in SILGen using SILGenThunk. This code is hard to
test and there is a lot of it. By using an instruction here we get a few benefits:
1. We decouple SILGen from needing to generate new kinds of thunks. This means
that SILGenThunk does not need to expand to handle more thunks.
2. All thunks implemented via ThunkInst will be easy to test in a decoupled way
with SIL tests.
3. Even though this stabilizes the patient, we still have many thunks in SILGen
and various parts of the compiler. Over time, we can swap to this model,
allowing us to hopefully eventually delete SILGenThunk.
As the optimizer uses more and more AST stuff, it's now time to create an "AST" module.
Initially it defines following AST datastructures:
* declarations: `Decl` + derived classes
* `Conformance`
* `SubstitutionMap`
* `Type` and `CanonicalType`
Some of those were already defined in the SIL module and are now moved to the AST module.
This change also cleans up a few things:
* proper definition of `NominalTypeDecl`-related APIs in `SIL.Type`
* rename `ProtocolConformance` to `Conformance`
* use `AST.Type`/`AST.CanonicalType` instead of `BridgedASTType` in SIL and the Optimizer
