sil-verifier was using SIL types to check metatypes. But metatypes, especially metatypes of metatypes, use AST types. Therefore checks should be done based on AST types.
rdar://20153162
Swift SVN r26111
We discussed it with Joe and this requirement does not make sense, especially if casts are produced by one pass, but optimized by another one. Moreover, having equal from and to types is eventually not very efficient, but is not semantically wrong. Such casts can often be produced by the inliner or specialised.
Swift SVN r26110
This makes it easier to diff and read SIL output. Since it is behind the -emit-sorted-sil
flag, there is no effect on normal compilation.
Swift SVN r26101
Give SILType 'getPreferredExistentialRepresentation' and 'canUseExistentialRepresentation' methods, which track what types of container particular existential types may use--fixed-sized, class-constrained, metatype, or box. Allow for existentials to use a specialized representation for certain known concrete types by allowing these methods to take a concrete type. NFC yet, except to replace some ad-hoc verifier conditions with canUseExistentialRepresentation checks where appropriate.
Swift SVN r26062
This can only happen in the closure specializer and the generic
specializer since all other specializations either copy the linkage of
the original function (function signature opts) or clone closures/thunks
which have shared linkage.
I put in a verifier check that makes sure we do not create shared
versions of these functions. The real problem has to do with serializing
these sorts of functions, but since we always serialize shared
functions, it makes sense to just ban it.
rdar://20082696
Swift SVN r26001
This is useful for cleaning-up the code generated by intermediate transformations, e.g. for cases where we perform folding of always failing casts into traps followed by an unreachable instruction. I'll make use of it in my subsequence commits.
Swift SVN r25988
This is only used by SILModule but is not integral to a SILModule so it makes
sense to have it in its own file. It keeps SILModule.cpp more focused. We still
keep it in a private header though since it is only meant to be used by
SILModule.cpp.
Swift SVN r25985
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
