The buffer of global arrays could already be statically initialized.
The missing piece was the array itself, which is basically a reference to the array buffer.
For example:
```
var a = [1, 2, 3]
```
ends up in two statically initialized globals:
1. the array buffer, which contains the elements
2. the variable `a` which is a single reference (= pointer) of the array buffer
This optimization removes the need for lazy initialization of such variables.
rdar://127757554
Add a unit test harness to SwiftCompilerSources to match the one in C++ since
both source bases have different implementations of the same utilities, and they
must be consistent for correctness.
If an argument escapes in a called function, we don't know anything about the argument's side effects.
For example, it could escape to the return value and effects might occur in the caller.
Fixes a miscompile
https://github.com/apple/swift/issues/73477
rdar://127691335
The copy operator has been implemented and doesn't use it. Remove
`Builtin.copy` and `_copy` as much as currently possible.
Source compatibility requires that `_copy` remain in the stdlib. It is
deprecated here and just uses the copy operator.
Handling old swiftinterfaces requires that `Builtin.copy` be defined.
Redefine it here as a passthrough--SILGen machinery will produce the
necessary copy_addr.
rdar://127502242
Changes in this CR add part of the, Swift based, Autodiff specific
closure specialization optimization pass. The pass does not modify any
code nor does it even exist in any of the optimization pipelines. The
rationale for pushing this partially complete optimization pass upstream
is to keep up with the breaking changes in the underlying Swift based
compiler infrastructure.
Compute, update and handle borrowed-from instruction in various utilities and passes.
Also, used borrowed-from to simplify `gatherBorrowIntroducers` and `gatherEnclosingValues`.
Replace those utilities by `Value.getBorrowIntroducers` and `Value.getEnclosingValues`, which return a lazily computed Sequence of borrowed/enclosing values.
Under OSSA, the instruction may still be structurally responsible for consuming
its operand even if the result is dead, so we can't remove it without breaking
invariants.
More generally, this should probably apply to any instruction which consumes
one or more of its operands, has no side effects, and doesn't produce any
nontrivial results that require further consumption to keep the value alive.
I went with this targeted fix, since it addresses a problem that shows up
in practice (rdar://125381446) and the more general change appears to
disturb the optimizer pipeline while building the standard library.
ClosureLifetimeFixup now emits mark_dependence [nonescaping]. Those should be
ignored by diagnostics. In the capture case, the dependence has already been
resolved, and may not match the SIL patterns that we expect for source-level
lifetime dependencies.
Fixes rdar://125375685 ([nonescapable] Fix lifetime-dependence diagnostics in the stdlib)
Don't treat StoreBorrow addresses as unknown bases. While they are never the base of a formal access, they are returned
as the AccessBase when querying the enclosing scope of an address.
