Currently we delete dead drop_deinit instructions in InstructionDeleter.
For address results, we may end up with ownership errors after being promoted to value forms.
For value results, fixLifetimes mode of InstructionDeleter will insert an illegal destroy_value
rdar://151104993
It derives the address of the first element of a vector, i.e. a `Builtin.FixedArray`, from the address of the vector itself.
Addresses of other vector elements can then be derived with `index_addr`.
Instead of passing in the substituted type, we pass in the
InFlightSubstitution. This allows the substituted type to be
recovered if needed, but we can now skip computing it for
the common case of LookUpConformanceInSubstitutionMap.
In language 6 mode keypath instructions are created as existentials and the optimizer needs to look through the `open_existential_ref` instructions to recognize a keypath.
rdar://150173106
When the utility is used by the ConsumeOperatorCopyableValuesChecker,
the checker guarantees that the lifetime can end at the consumes, that
there are no uses after those consumes. In that circumstance, the
utility maintains liveness to those consumes and as far as possible
without introducing a copy everywhere else.
The lack of complete lifetimes has forced the utility to extend liveness
of values to dead-ends. That extension, however, is in tension with the
use that the checker is putting the utility to. If there is a dead-end
after a consume, liveness must not be maintained to that dead-end.
rdar://147586673
Need to canonicalize the replacement type. Otherwise it could be generic if it is a typealias inside a generic type, e.g.
```
struct S<T> {
typealias I = Int
}
```
Otherwise, we can be inconsistent with isolations returned by other parts of the
code. Previously we were just treating it always as self + nom decl, which is
clearly wrong if a type is not self (e.x.: if it is an isolated parameter).
rdar://135459885
I am doing this so I can mark requires as being on a mutable non-Sendable base
from a Sendable value.
I also took this as an opportunity to compress the size of PartitionOp to be 24
bytes instead of 40 bytes.
Addressable parameters must remain indirect.
Incidentally also fixes an obvious latent bug in which all specialization was
disabled if any metatypes could not be specialized.
Fixes rdar://145687827 (Crash of inline-stored Span properties with optimizations)
* `sitofp` signed integer to floating point
* `rint` round floating point to integral
* `bitcast` between integer and floating point
Constant folding `bitcast`s also made it necessary to rewrite constant folding for Nan and inf values, because the old code explicitly checked for `bitcast` intrinsics.
Relying on constant folded `bitcast`s makes the new version much simpler.
It is important to constant fold these intrinsics already in SIL because it enables other optimizations.
This is a narrow fix, we are going to work on fixing this properly
and allowing both devirtualization and specialization for distributed
requirement witnesses.
Anything that uses an ad-hoc serialization requirement scheme cannot
be devirtualized because that would result in loss of ad-hoc conformance
in new substitution map.
Resolves: https://github.com/swiftlang/swift/issues/79318
Resolves: rdar://146101172
When performing a dynamic cast to an existential type that satisfies
(Metatype)Sendable, it is unsafe to allow isolated conformances of any
kind to satisfy protocol requirements for the existential. Identify
these cases and mark the corresponding cast instructions with a new flag,
`[prohibit_isolated_conformances]` that will be used to indicate to the
runtime that isolated conformances need to be rejected.
The body of a function has to be re-analyzed for every call
site of the function, which is very expensive and if the
body is not changed would produce the same result.
This takes about ~10% from swift-syntax overall build time
in release configuration.
We need to consider that archetypes (generic types) can be existentials if they conform to self-conforming protocols.
Fixes a miscompile
rdar://147269904
