The checker already verifies that no non-destroy consuming users occur
after any `move_value`s corresponding to `consume` operators applied to
a value. There may, however, be _destroy_ users after it.
Previously, the checker did not shorten the lifetime from those destroys
up to `move_value`s that appear after those `move_value`s. The result
was that the value's lifetime didn't end at the `consume`.
Here, the checker is fixed to rewrite the lifetimes so that they both
end at `consume`s and also maintain their lexical lifetimes on paths
away from the `consume`s. This is done by using
`OwnedValueCanonicalization`/`CanonicalizeOSSALifetime`.
Specifically, it passes the `move_value`s that correspond to
source-level `consume`s as the `lexicalLifetimeEnds` to the
canonicalizer. Typically, the canonicalizer retracts the lexical
lifetime of the value from its destroys. When these `move_value`s are
specified, however, instead it retracts them from the lifetime boundary
obtained by maximizing the lifetime within its original lifetime while
maintaining the property that the lifetime ends at those `move_value`s.
rdar://113142446
An empty struct without a deinit gets a single bit which is used to
track the struct's liveness. Previously, an empty struct with a deinit
also only got a single bit. Consequently, when discarding the struct
(i.e. dropping the deinit), there was no bit left to represent the
struct. This resulted in a failure to track liveness for the value.
rdar://126863003
This commit modifes the constant folder to not handle equality comparisons b/w
infinity and non-infinity operands. In such comparisons, special floating point
types - Float80 and Float16, may come into play and pattern matching againt them
complicates the constant folding logic more than we'd like.
Previously, `isScopeAffectingInstructionDead` determined that
an otherwise satisfactory `load` was not dead if it was a `load [take]`.
The immediate effect was that dead `load [take]`s were not deleted. The
downstream effect was that otherwise dead graphs of instructions would
not be deleted. This was especially a problem for OSLogOptimization
which deletes a great deal of code.
Here, the InstructionDeleter is taught to compensate for the deletion of
such `load [take]` by inserting `destroy_addr`s in their stead.
rdar://117011668
Before move-checking values, complete the lifetimes of all the values
derived from them via copy, borrow, and move.
Collect all such values and their derived transitive values and then
complete the lifetimes of each, visiting the instructions which produce
them in post-order.
Once OSSALifetimeCommpletion runs as part of SILGenCleanup, this code
can be deleted.
We already use a complexity limit for other functions in AliasAnalysis.
This is a workaround for quadratic complexity in ARCSequenceOpts.
Fixes a compile time problem
rdar://114352817
The metatype param may or may not be removed from the callee during
specialization. If it is, there is only one argument, if it is not,
there are two arguments. None of that is relevant to this test case.
It is just verifying that the strong_retain occurs before the apply.
`Dictionary.init(dictionaryLiteral:)` was annotated
`@_effects(readonly)` which means among other things that it doesn't
release any references. Being an init, however, it consumes its
arguments, and so does in fact release.
rdar://114699006
IRGen crashed in case an enum, which has a 24 bit payload (e.g. three `UInt8`), is used as a payload of another enum, e.g. `Optional`, in a statically initialized global variable.
rdar://112823823
The main change here is in IRGen which needs to be able to emit constant enum values.
Use `emitValueInjection` to create the enum constant.
Usually this method creates code in the current function.
But if all arguments to the enum are constant, the builder never has to emit an instruction.
Instead it can constant fold everything and just returns the final constant.
Also, create statically initialized let-globals as constant global (`constant` instead of `global`).
For very large control flow graphs the markControllingTerminatorsLive can stack overflow.
Fix this by doing the work iteratively instead of recursively.
rdar://106198943
The `isEscaping` function is called a lot from ARCSequenceOpt and ReleaseHoisting.
To avoid quadratic complexity for large functions, limit the amount of work what the EscapeUtils are allowed to to.
This keeps the complexity linear.
The arbitrary limit is good enough for almost all functions.
It lets the EscapeUtils do several hundred up/down walks which is much more than needed in most cases.
Fixes a compiler hang
https://github.com/apple/swift/issues/63846
rdar://105795976
