A failable initializer that ended in an unconditional 'return nil' was leaving the exit basic block unemitted, since we exited early before writing out the unreachable epilog. Thanks Chris for catching this.
Swift SVN r21491
This will let the performance inliner inline a function even if the costs are too high.
This attribute is only a hint to the inliner.
If the inliner has other good reasons not to inline a function,
it will ignore this attribute. For example if it is a recursive function (which is
currently not supported by the inliner).
Note that setting the inline threshold to 0 does disable performance inlining at all and in
this case also the @inline(__always) has no effect.
Swift SVN r21452
Since we preserve a single exit point in SIL, provide a join point with a BB argument to receive the success or failure result to return.
Swift SVN r21450
Introduce an attribute that describes when a given CF type is
toll-free-bridged to an Objective-C class, and which class that
is. Use that information in the type checker to provide the CF <->
Objective-C toll-free-bridged conversions directly, rather than using
the user-defined conversion machinery.
Swift SVN r21376
Fixes an attempt to perform vtable dispatch to an initializer that was
defined in an extension and is not @objc, which means it had no vtable
entry <rdar://problem/17909833>.
Swift SVN r21352
Replace the true/maybe state that Builtin.canBeClass was returning by a
tri-state (yes, no, maybe) allowing the optimizer to use the definite no
answer. This removes the need of the sizeof check that we had in
isClassOrObjCExistential. It also removes the need to CSE this function since
in most cases we will be able to instantiate canBeClass to yes or no (vs maybe)
at compile time.
benchmark``````````````,``baserun0``,``optrun2``,``delta,``speedup
ClassArrayGetter```````,``988.00````,``337.00```,``644.00``,````````191.7%
DeltaBlue``````````````,``2429.00```,``1927.00``,``460.00``,````````23.9%
Dictionary`````````````,``1374.00```,``1231.00``,``129.00``,````````10.9%
Havlak`````````````````,``1079.00```,``911.00```,``124.00``,````````13.7%
Rectangles`````````````,``924.00````,``541.00```,``379.00``,````````70.1%
radar://16823238
Swift SVN r21331
This disables inlining at the SIL level. LLVM inlining is still enabled. We can
use this to expose one function at the SIL level - which can participate in
dominance based optimizations but which is implemented in terms of a cheap check
and an expensive check (function call) that benefits from LLVM's inlining.
Example:
The inline(late) in the example below prevents inlining of the two checks. We
can now perform dominance based optimizations on isClassOrObjExistential.
Without blocking inlining the optimizations would apply to the sizeof check
only and we would have multiple expensive function calls.
@inline(late)
func isClassOrObjExistential(t: Type) -> Bool{
return sizeof(t) == sizeof(AnyObject) &&
swift_isClassOrObjExistential(t)
}
We do want inlining of this function to happen at the LLVM level because the
first check is constant folded away - IRGen replaces sizeof by constants.
rdar://17961249
Swift SVN r21286
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
r21096 introduces an optimization barrier for failing initializers
that allows the pattern
let x: NSFoo? = NSFoo()
be used to detect whether NSFoo() returned nil, even though the type
system says it cannot. Extend this check to Objective-C methods and
properties, where the non-optional annotation may be incorrect
<rdar://problem/17984530>.
Swift SVN r21176
If we see that we're injecting the result of an @objc initializer into an optional, perform the T -> T? conversion using unchecked_ref_bit_cast, which is opaque to the optimizer, instead of doing a proper optional injection. This prevents the optimizer from defeating our workaround for failing initializers. <rdar://problem/17941601>
Swift SVN r21096
as a std::vector<std::unique_ptr<PathComponent>>. DiverseList memcpy's
around its buffer on copy and move operations. This seems safe with all
of the current implementations of Cleanup, but is absolutely not with the
LValue PathComponents. These things hold std::vectors, RValue (which has
an std::vector in it), and a bunch of other probably non-trivial things.
While we're in here, disable the copy constructor, since it isn't safe.
This doesn't harm mainline, but was burning me on a patch I'm working on.
When/if someone cares about performance optimizing this code, a better
approach would be to use an ilist + bump pointer allocator.
Swift SVN r21057
"self" for class-constrained witnesses is still passed at +1, so we can't load it using AllowPlusZero. Fixes <rdar://problem/17852846>.
Swift SVN r20868
a concrete SILValue when emitting the Callee object so we can look things up
in method tables etc. Without reengineering all of Callee, that isn't going
to work.
Swift SVN r20727
behaviorly correct code by CSE'sing subscripts that are identical.
Also, add a dump() method to PathComponent to help visualize / debug LValue structures.
Swift SVN r20661
computed property" errors when SILGen could determine that there was
an inout writeback alias, and have the code instead perform CSE of the
writebacks directly.
This means that we produce more efficient code, that a lot of things
now "just work" the way users would expect, and that the still erroneous
cases now get diagnosed with the "inout arguments are not allowed to
alias each other" error, which people have a hope of understanding.
There is still more to do here in terms of detecting identical cases,
but that was true of the previous diagnostic as well.
Swift SVN r20658
getNextUncurryLevelRef was using it's own local test to determine whether a
FuncDecl is dynamically dispatched (which didn't check for "final"), change it
to use SILGenFunction::getMethodDispatch instead.
Swift SVN r20623
Factor out the code for emitting the "bind" branching logic, and share it to implement an LValueComponent for optional binds, which makes optional assignments work.
Swift SVN r20614
t2.swift:4:11: error: inout arguments are not allowed to alias each other
swap(&x, &x)
^~
t2.swift:4:7: note: previous aliasing argument
swap(&x, &x)
^~
This can (and arguably should) also be handled with a later diagnostic pass, but
handling it in SILGen gives us full range emission capability.
Swift SVN r20469
include the index which is confusing. For example, in:
func testMultiArray(i : Int, j : Int, var array : [[Int]]) {
swap(&array[i][j], &array[i][i])
}
we now highlight just "array[i]", instead of the subsequent "j" and "i"'s.
Swift SVN r20446
We were attempting to find the vtable slot for the allocating
initializer in the superclass, but of course it doesn't have one. Part
of <rdar://problem/17408284>.
Swift SVN r20429
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
lower to different SILValue's are actually identical. These are the expression involved
in turning an integer literal into an expression. This is totally a hack in that we assume
that all "convertFromIntegerLiteral" are side effect free, but is close enough to be useful
for this diagnostic. The right answer is to implement real attributes to model this
(rdar://15587352).
That said, this diagnostic is pretty useful as it is. For example, the SwiftWTF blog post
(http://swiftwtf.tumblr.com/post/91934970718/xcode-6-beta-3) has two examples. The first
one passes this diagnostic unscathed because there is no inout aliasing problem: "a" is a
physical lvalue, not a logical one and a[1] doesn't alias a[2].
However, the second example is now rejected with an error message of:
t.swift:12:18: error: inout writeback through subscript occurs in multiple arguments to call, introducing invalid aliasing
swap(&aa[0][1], &aa[0][2])
^~~~~ ~
t.swift:12:7: note: concurrent writeback occurred here
swap(&aa[0][1], &aa[0][2])
^~~~~ ~
This is a violation even though "aa" is physical lvalue, because "aa[0]" is a logical
lvalue and we can now detect that the two instances of "aa[0]" are identical (because
we can tell the two 0's are identical). I'm still not thrilled with the diagnostic, but
I think this will help stem a common source of problems in practice.
As more lvalues become physical or get auto-CSE'd (either with better SILGen CSE, with
physical i addressors, etc) this diagnostic will automatically track SILGen.
Swift SVN r20377
handle cases where the index lowers to exactly identical SILValue's. This is presently
pretty uncommon (except in the moderately common case of a direct reference to a "let Int"),
but is a nice base case.
The diagnostic we now get is:
t.swift:5:23: error: inout writeback through subscript occurs in multiple arguments to call, introducing invalid aliasing
swap(&array[i][j], &array[i][i])
^~~~~~~~ ~
t.swift:5:9: note: concurrent writeback occurred here
swap(&array[i][j], &array[i][i])
^~~~~~~~ ~
based on the fact that "i" lowers to the same SILValue.
Swift SVN r20376
The type checker produces nested optional evaluations for expressions of the form 'x.optionalProperty?.optionalProperty as NonOptionalType'. SILGen had a peephole for this case that was apparently never tested, because we tried to dereference a null failure BB. Fixes <rdar://problem/17576873> and at least half a dozen dupes. The codegen is still kind of ridiculous, but correct.
Swift SVN r20358
introduced, as these are obvious miscompilations and clearly mystifying to our user base.
This is enough to emit diagnostics like this:
writeback_conflict_diagnostics.swift:58:70: error: inout writeback aliasing conflict detected on computed property 'c_local_struct_property'
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
writeback_conflict_diagnostics.swift:58:33: note: concurrent writeback occurred here
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
which isn't great, but is better than nothing (better wording is totally welcome!).
This doesn't handle subscripts (or many other kinds of logical lvalue) at all yet, so
it doesn't handle the swift WTF case, but this is progress towards that.
Swift SVN r20297
