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.
As with the lexical flag, when creating an alloc_stack corresponding to
an alloc_box, transfer the var_decl flag from any begin_borrow users of
the box.
This fixes use-after-free miscompilation bugs that can occur when a
lifetime-optimized standard library type, like Dictionary or String is
converted to an UnsafePointer using implicit inout-to-pointer
conversion:
func ptrToDictionary(_: UnsafePointer<Dictionary<K, V>>) {}
func testDictionary() {
var d: Dictionary = ...
ptrToDictionary(&d)
}
func ptrToString(_: UnsafePointer<String>) {}
func testString() {
var s: String = ...
ptrToString(&s)
}
Address to pointer conversion must always be guarded by either a
mark_dependence or a fix_lifetime. Use fix_lifetime for call emission
in SILGen to limit the optimization impact to the narrow scope of the
pointer conversion.
This could negatively impact performance simply because SIL does not
provide a way to scope pointer conversion. fix_lifetime is
unnecessarilly conservative and prevents the elimination of dead
allocations.
rdar://117807309 (Fix SILGen to emit fix_lifetime for
inout-to-pointer conversion)
Due to mismatch in the instructions handled in DestroyHoisting::getUsedLocationsOfInst
and MemoryLocations::analyzeLocationUsesRecursively, certain users of addresses
were not considered and the destroys were hoisted before valid uses causing use-after-frees
Use the new builtins for COW representation in Array, ContiguousArray and ArraySlice.
The basic idea is to strictly separate code which mutates an array buffer from code which reads from an array.
The concept is explained in more detail in docs/SIL.rst, section "Copy-on-Write Representation".
The main change is to use beginCOWMutation() instead of isUniquelyReferenced() and insert endCOWMutation() at the end of all mutating functions. Also, reading from the array buffer must be done differently, depending on if the buffer is in a mutable or immutable state.
All the required invariants are enforced by runtime checks - but only in an assert-build of the library: a bit in the buffer object side-table indicates if the buffer is mutable or not.
Along with the library changes, also two optimizations needed to be updated: COWArrayOpt and ObjectOutliner.
test/SILOptimizer/pointer_conversion.swift’s arrayLiteralPromotion() subtest uses integer literals for 41, 42, 43, and 44. If swift-evolve shuffles a particular _internalInvariant() call in stdlib/public/core/BridgeStorage.swift to lines 41-44, the compiler will generate code which reuses the integer_literal instruction for the line number later in the test, causing this test to fail. This happens about once per 45 runs of swift-evolve.
This change negates the integer literals so they will never match a line number.
* Implement a few silcombine transformations for arrays
- Useless existential_ref <-> class conversions.
- mark_dependence_inst depending on uninteresting instructions.
- release(init_existential_ref(x)) -> release(x) when hasOneUse(x)
- Update COWArrayOpt to handle the new forms generated by this.
these aren't massive performance wins, but do shrink the size of SIL when
dealing with arrays.
* Generalize testcase to work on linux and on mac when checking stdlib is enabled.
I looked at trying to make the matches more flexible, but there are
actually some suspicious bits that I'm not so sure about. I'll just
disable the test for now.
rdar://problem/33531741
The array or string has to be kept alive past the call. John fixed
this back in 733915f but I want to make sure it doesn't regress.
rdar://problem/31325077 (originally fixed as rdar://problem/31542269,
also reported as SR-3231)
