This will eventually be required for C++. It is also, apparently,
required for anonymous structs that are used as the type of a
named field.
Should unblock the Linux Foundation build.
initialization in-place on demand. Initialize parent metadata
references correctly on struct and enum metadata.
Also includes several minor improvements related to relative
pointers that I was using before deciding to simply switch the
parent reference to an absolute reference to get better access
patterns.
Includes a fix since the earlier commit to make enum metadata
writable if they have an unfilled payload size. This didn't show
up on Darwin because "constant" is currently unenforced there in
global data containing relocations.
This patch requires an associated LLDB change which is being
submitted in parallel.
Eventually, we decided to do this
1. Have the function signature opts (used to be called the cloner to create
the optimized function.
2. Mark the thunk as always_inline
3. Rely on the inliner to inline the thunk to get the benefit of calling optimized
function directly.
fulfillments, because we don't actually fill them in.
This is a minimal, temporary, speculative fix for the failure
described in rdar://25069637, for which I unfortunately do not have
a minimal test case and which I have been unable to duplicate in
my own testing due to various language restrictions that I hope
to lift given the better (but temporarily reverted) fix.
We decided to use the inliner to rewrite the caller's callsites.
And eventually I will turn FunctionSignatureAnalysis into a Utility.
As its data should only be used and kept in the cloner pass.
This forces the callsites to be rewritten by the inliner.
we have the issue that the thunk changes from the time the its created to
the time its reread to figure out what we have done to the original function
This results in missed opportunities.
This solution solves the problem gracefully, because the thunk carries the information
on how to set up the call to the optimized functions.
Inlining the thunk makes the callsite calling the optimized function for free. i.e.
without any rewriting.
I did not measure any regression with this change.
Use it for hashing and comparison.
During String's hashValue and comparison function we create a
_NSContiguousString instance to call Foundation's hash/compare function. This is
expensive because we have allocate and deallocate a short lived object on the
heap (and deallocation for Swift objects is expensive). Instead help the
optimizer to allocate this object on the stack.
Introduces two functions on the internal _NSContiguousString:
_unsafeWithNotEscapedSelfPointer and _unsafeWithNotEscapedSelfPointerPair that
pass the _NSContiguousString instance as an opaque pointer to their closure
argument. Usage of these functions asserts that the closure will not escape
objects transitively reachable from the opaque pointer.
We then use those functions to call into the runtime to call foundation
functions on the passed strings. The optimizer can promote the strings to the
stack because of the assertion this API makes.
let lhsStr = _NSContiguousString(self._core) // will be promoted to the stack.
let rhsStr = _NSContiguousString(rhs._core) // will be promoted to the stack.
let res = lhsStr._unsafeWithNotEscapedSelfPointerPair(rhsStr) {
return _stdlib_compareNSStringDeterministicUnicodeCollationPointer($0, $1)
}
Tested by existing String tests.
We should see some nice performance improvements for string comparison and
dictionary benchmarks.
Here is what I measured at -O on my machine
Name Speedup
Dictionary 2.00x
Dictionary2 1.45x
Dictionary2OfObjects 1.20x
Dictionary3 1.50x
Dictionary3OfObjects 1.45x
DictionaryOfObjects 1.40x
SuperChars 1.60x
rdar://22173647
This attribute is a stand-in for the versioning annotations
described in docs/LibraryEvolution.rst; right now it's just present
or absent, and its only effect is to make sure versioned internal
decls are treated as public at the SIL level. (This functionality
already existed for -enable-testing, so it can probably be trusted.)
Also, allow inlineable functions to reference transparent and
inline-always functions /if/ they're only called immediately (not used
as values or partial-applied), since they'll be inlined away before
emitting IR. (We should really only allow this /before/ mandatory
inlining, but we don't have a separate SIL stage for that.)
If a thunk is referenced from two different functions, the thunk inherits
the fragile attribute from the first function that forced it to be emitted.
This is wrong, in case the first function might not be fragile, while
the second one is. Copying the fragile attribute to an existing thunk when
checking if it has already been emitted is also wrong, because the thunk
might reference another thunk, and so on.
The correct fix is to have SIL serialization serialize the transitive
closure of all fragile functions and thunks referenced from fragile
functions. Re-work SIL function serialization to use a worklist so that
we can do this.
Part of https://bugs.swift.org/browse/SR-267.
This ensures their bodies are fragile in SIL. While they can
be synthesized again, this change will avoid tripping up the
SIL verifier after some upcoming changes.
Part of https://bugs.swift.org/browse/SR-267.
A transparent function might be deserialized and inlined into a function
in another module, which would cause problems if the function referenced
local functions.
Previously we would force local functions to have public linkage instead,
which worked, but was not resilient if the body of the transparent
function changed in the module that contained it.
Add a library evolution test ensuring that such a change is resilient
now.
Part of https://bugs.swift.org/browse/SR-267.
The optimization pass was inspecting only init methods to determine if a given let property is defined
in the same way by all initializers. But this is not enough in certain cases, e.g. when some of the
initializers were inlined into the application code and the body of the inlined SIL function representing
such an initializer was removed afterwards by the dead function elimination pass. In such situations,
the Let Properties Optimization pass was assuming that there is only one initializer and considered the
constant let property value defined there as the only possible value of this let property. Therefore it
propagated it into let-property uses, which resulted in an incorrect code.
The right thing to do is to analyze all assignments to a given let property whether they are inside initializer
SIL functions or not. This makes sure that all possible values of a let property are analyzed and compared.
The propagation of a constant let property value can only happen if all found possible values are all the same.
Fixes SR-1026 and rdar://25303106
initialization in-place on demand. Initialize parent metadata
references correctly on struct and enum metadata.
Also includes several minor improvements related to relative
pointers that I was using before deciding to simply switch the
parent reference to an absolute reference to get better access
patterns.
The AvailabilityWalker was creating a new AvailabilityWalker instance whenever it
recursed through an assignexpr or memberrefexpr, which produced a new ExprStack.
This caused the fixit mechanics for migrating ++/-- to think that the ++/-- was
at the top level, when it wasn't.
In the Clang importer, and only in submodules, the first protocol
typedef with NSObject that we try to import results in a hidden lookup
result. So, allow hidden lookups, which is benign and failure is
actually an issue of a malformed header. Gracefully handles failure.
Test case included that will reproduce the issue if AllowHidden is
disabled.
It is a common problem that people use a call to a function with a
trailing closure in a if condition, foreach loop, etc. These don't allow
trailing closures, because they are ambiguous with the brace-enclosed body
of the conditional statement.
In an effort to improve QoI on this, perform lookahead to disambiguate the most common
form of this, in a very narrow situation. This allows us to produce a nice error
with fixit hints like:
t.swift:26:25: error: trailing closure requires parentheses for disambiguation in this context
for _ in numbers.filter {$0 > 4} {
^
instead of spewing out this garbage:
t.swift:26:26: error: anonymous closure argument not contained in a closure
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:33: error: consecutive statements on a line must be separated by ';'
for _ in numbers.filter {$0 > 4} {
^
;
t.swift:26:34: error: statement cannot begin with a closure expression
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:34: note: explicitly discard the result of the closure by assigning to '_'
for _ in numbers.filter {$0 > 4} {
^
_ =
t.swift:26:34: error: braced block of statements is an unused closure
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:18: error: type '(@noescape (Int) throws -> Bool) throws -> [Int]' does not conform to protocol 'Sequence'
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:34: error: expression resolves to an unused function
for _ in numbers.filter {$0 > 4} {
^
set where all members of the set produce the same type, produce a more
specific error.
Before:
t.swift:4:17: error: no '&&' candidates produce the expected contextual result type 'Int'
return a == b && 1 == 2
^
t.swift:4:17: note: produces result of type 'Bool'
return a == b && 1 == 2
^
after:
t.swift:4:17: error: '&&' produces 'Bool', not the expected contextual result type 'Int'
return a == b && 1 == 2
^
This improves the situation reported in https://twitter.com/_jlfischer/status/712337382175952896
Vedant Kumar
Xi Ge
Vedant Kumar
John McCall
Xin Tong
Stephen Canon
Greg Titus
Arnold Schwaighofer
Stephen Canon
Jordan Rose
Slava Pestov
Roman Levenstein
Chris Lattner
Doug Gregor
Michael Ilseman