This fixes two issues that I ran into with the devirtualizer and also
paves the path to more simplification of the devirtualizer code.
Both issues are due to having a very liberal definition of what can be
considered an upcast.
In one case, we tunnel through an unchecked_ref_cast and then fail to
devirtualize because the source type is not a class
type (rdar://problem/20115523). We would be better off sticking to the
class type we started with.
In the other case, we tunnel through an unchecked_ref_bit_cast and this
results in an attempt to insert a checked_cast_br between unrelated
types (rdar://problem/20117782).
Swift SVN r25976
For better consistency with other address-only instruction variants, and to open the door to new exciting existential representations (such as a refcounted boxed representation for ErrorType).
Swift SVN r25902
Turns out llvm::DataLayoutPass is used in other places, so the bots are still unhappy.
Re-applying the original change so we can fix the problem holistically.
Swift SVN r25761
This is breaking the testing bot because DataLayoutPass was just removed from LLVM trunk.
Chris is the best one to fix this change, but we need to get the bots green.
Swift SVN r25760
- Have Sema, not SILGen decide if a vardecl can be captured by address
instead of by-box. This is a non-local property that is best computed
during capture set formation. Sema captures this as a bit on the new
CapturedValue entry.
- Rework some diagnostic emission to centralize a class of noescape
diagnostics in capture set calculation. Previously, funcdecl closures
produced their diagnostics there, but ClosureExprs produced them in
MiscDiagnostics (NFC for this part).
This fixes <rdar://problem/19981118> Swift 1.2 beta 2: Closures nested in @noescape closures copy, rather than reference, captured vars.
Swift SVN r25759
the DeclRefExpr's access semantics is "direct to storage" instead of basing it
on the weird special case we were using before.
- Change AST dumper to print the "direct" flag.
NFC.
Swift SVN r25749
when computing the list. This simplifies getLocalCaptures to *just* filter out
global captures, and paves the way for other enhancements. NFC.
Swift SVN r25739
When we clone loops with exit blocks that are unreachable the verifier
complained before this patch.
loop:
= alloc_stack
cond_br %overflow_cond, loop_latch, unreachable_only_exit
loop_latch:
cond_br loop, exit
unreachable_only_exit:
..
unreachable
We don't care about stack deallocation on paths that must lead to
unreachable.
The alternative to weaken the verifier for cases like this would be to clone
loop exits that are guaranteed to lead to unreachable which would be a waste of
space.
Swift SVN r25732
This patch does the following:
- Improvements and correctness fixes for conversions of existential metatypes. They may succeed if you have a concrete or existential metatype that conforms to the protocol. Based on Joe's review of my previous patch.
- Removes special-cases for AnyObject. AnyObject is handled as any other class existential.
- Improves folding of conversions from class existential metatypes to concrete non-class metatypes
- Improves comments.
- Adds more tests to cover new test-cases.
- Adjusts a few existing tests.
Swift SVN r25690
If we have a C function pointer conversion, generate a thunk using the same logic we use for ObjC method thunks, and emit a pointer to that thunk as the C function pointer value. (This works for nongeneric, nonmember functions; generics will additionally need to apply generic parameters within the thunks. Static functions would need to gather the metatype as well.)
Swift SVN r25653
This patch does the following:
- Moves the logic for handling special-case of converting to/from AnyObject.Protocol (and existential.Protocol in general) into DynamicCasts, where all other cases are handled already.
- Moves the peephole which was folding checked_cast_br into an unchecked cast and branch from sil-combine into sil-simplify-cfg, because it is a better place for it, since this peephole affects the CFG. The corresponding test is also moved from sil_combine.sil into simplify_cfg.sil.
- Adds a few checked_cast_br peepholes to sil-combine. They try to simplify checked_cond_br instructions using existential metatypes by propagating a concrete type whenever it can be determined statically.
- Adds a new test with a lot of test-cases that make sure we are really folding many type-checks at compile-time now.
Swift SVN r25504
The logic for different special cases of type casting is spread over multiple places currently. This patch simply re-factors some of that code (folding of of type casts using statically known protocol conformances) and moves it into one central place, which makes it easier to maintain. Plus, it allows other clients of DynamicCasts benefit from it as well, e.g. the inliner can use this now. NFC.
Swift SVN r25486
If multiple swift files are compiled together, then guessing as to the
file when we emit IR obviously doesn't work. Find the filename when we
generate a function's coverage map and propagate it through SIL.
Swift SVN r25436
Keeping a reference to the function here is dangerous. We only
actually care about the name, so save ourselves a copy of that
instead.
This fixes a crash that seems to happen only when the coverage data is
very large.
Swift SVN r25433
This is just good to do and hopefully will help prevent people from forgetting
to check in the future by annotating the API explicitly as returning a
potentially nullptr.
Swift SVN r25364
This is also useful in general SIL passes when generating thunks. I am going to
use this in function signature optimization and closure specialization.
Swift SVN r25356
One common problem in swift code is the "reforming enum problem". What
happens here is that we have some enum %0 : $Optional<T> and we break it
apart and reform it as a new enum as in the following:
bb9:
...
switch_enum %0 : $Optional<T>, #Optional.None: bb10,
#Optional.Some: bb11
bb10:
%1 = enum $Optional<U>, #Optional.None
br bb12(%1 : $Optional<U>)
bb11:
%2 = some_cast_to_u %0 : ...
%3 = enum $Optional<U>, #Optional.Some, %2 : $U
br bb12(%3 : $Optional<U>)
bb12(%4 : $Optional<U>):
retain_value %0 : $Optional<T> // id %5
release_value %4 : $Optional<U> // id %6
We really would like to know that a retain on %4 is equivalent to a
retain on %0 so we can eliminate the retain, release pair. To be able to
do that safely, we need to know that along all paths %0 and %4 either:
1. Both refer to the same RCIdentity directly. An example of this is the
edge from bb11 -> bb12).
2. Both refer to the "null" RCIdentity (i.e. do not have a payload). An
example of this is the edge from bb10 -> bb12.
Only in such cases is it safe to match up %5, %6 and eliminate them. If
this is not true along all paths like in the following:
bb9:
...
cond_br %foo, bb10, bb11
bb10:
%1 = enum $Optional<U>, #Optional.None
br bb12(%1 : $Optional<U>)
bb11:
%2 = some_cast_to_u %0 : ...
%3 = enum $Optional<U>, #Optional.Some, %2 : $U
br bb12(%3 : $Optional<U>)
bb12(%4 : $Optional<U>):
retain_value %0 : $Optional<T> // id %5
release_value %4 : $Optional<U> // id %6
then we may have that %0 is always non-payloaded coming into bb12. Then
by matching up %0 and %4, if we go from bb9 -> bb11, we will lose a
retain.
Perf Changes:
TITLE..................OLD...........NEW...........NEW/OLD
LevenshteinDistance....1398195.00....1177397.00....0.84
Memset.................26541.00......23701.00......0.89
CaptureProp............5603.00.......5031.00.......0.90
ImageProc..............1281.00.......1196.00.......0.93
InsertionSort..........109828.00.....104129.00.....0.95
StringWalk.............6813.00.......7456.00.......1.09
Chars..................27182.00......30443.00......1.12
The StringWalk, Chars are both reproducible for me. When I turn back on parts of
the recursion (I took the recursion out to make this change more conservative),
the Chars regression goes away, but the StringWalk stays. I have not had a
chance to look at what is going on with StringWalk.
rdar://19724405
Swift SVN r25339
A type in an extension doesn't inherit linkage from its parent. In particular, if an extension adds a nested type to an imported class, we don't want that nested type to have unique linkage. Fixes rdar://problem/19792174.
Swift SVN r25191
These should never happen, but they are happening (rdar://problem/19777115), and not being able to print them when they do occur makes debugging onerous.
Swift SVN r25118
rdar://problem/19514920 is caused by a disagreement between IRGen and SILGen about which SILDeclRefs override vtable slots. Factor out the somewhat-hairy code in SILGen to a place IRGen will be able to share it. NFC yet.
Swift SVN r25063
This makes it easy to find no-return functions since one must iterate
through all BB with unreachable terminators and check the previous
instruction.
Swift SVN r25004
This will have an effect on inlining into thunks.
Currently this flag is set for witness thunks and thunks from function signature optimization.
No change in code generation, yet.
Swift SVN r24998
@noescape may be interesting to passes in the future, but it currently has no effect except to cause symbol collisions in reabstraction thunks and other places. Since it has no effect, just remove it from SIL for now.
Swift SVN r24925
Instead, just fall through to the normal public/internal/private switch
added in the previous commit. Local declarations are always private.
Make sure we emit all local declarations by using the list in the SourceFile,
rather than walking the AST (which missed a few cases and was less efficient
anyway).
As an exception, declarations without accessibility at all still get private
linkage. These are things like local variables that don't get accessed by
symbol, even when using the debugger.
rdar://problem/19623016
Swift SVN r24839
Easy cut down on exported symbols. Unless a private type is referenced in
an inlineable function, there's no way to generate a reference to it
outside of the current file, except in the debugger. (That last bit is why
we can't use fully private linkage, which would keep the symbol out of the
symbol table completely.)
We should be doing this for "internal" declarations as well, but the
standard library /does/ have references to internal types in inlineable
functions, and also has tests that directly access these types.
Swift SVN r24838
