when computing the list. This simplifies getLocalCaptures to *just* filter out
global captures, and paves the way for other enhancements. NFC.
Swift SVN r25739
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
Creation of witness_method instructions already handles creation of the
witness table in cases where it doesn't already exist, so this code is
not needed.
Swift SVN r25547
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
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 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
This is similar to UnaryInstructionBase's getOperandRef(). Sometimes, we want to
store a pointer to an operand in a temporary data structure such as a visited
set.
Swift SVN r24958
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
Previously I was using a large SmallVector to create Nodes for the
ProjectionTree. This created an issue when the SmallVector would convert
from small to large representation in the middle of a method on an
object that is stored in the SmallVector. Thus the 'this' pointer will
be invalidated and all sorts of fun times will occur.
I switched now to using a BumpPtrAllocator which is passed into the tree
and used in FunctionSignatureOptimization for all projection trees.
<rdar://problem/19534462>
Swift SVN r24706
Write up a requireABICompatibleFunctionTypes check to make sure two function types share the same ABI. The real target here is to be able to apply this to vtable entries in order to uncover variance bugs like rdar://problem/19321484, but convert_function is a convenient testbed.
Swift SVN r24666
1. Eliminate unused variable warnings.
2. Change field names to match capitalization of the rest of the field names in the file.
3. Change method names to match rest of the file.
4. Change get,set method for a field to match the field type.
Swift SVN r24501
memory layout and add a SelectInst API that allows for one to access select inst
operands when one does not care about what the cases actually are.
Previously select_enum, select_enum_addr had the following memory layout:
[operands], [cases]
In constrast, select_value had the following layout:
[operand1, case1, operand2, case 2, ...]
The layout for select_value makes it impossible to just visit operands in a
generic way via a higher level API. This is an important operation for many
analyses such as AA on select insts.
This commit does the following:
1. Adds a new abstract parent class for all select instructions called
SelectInst.
2. Adds a new templated implementation parent class that inherits from
SelectInst called SelectInstBase. This handles the complete implementation of
select for all types by templating on CaseTy.
3. Changes SelectEnumAddrInst, SelectEnumInst, SelectValueInst to be thin
classes that inherit from the appropriately specialized SelectInstBase.
I left in SelectEnumInstBase for now as a subclass of SelectInstBase and parent
class of SelectEnum{,Addr}Inst since it provides specific enum APIs that are
used all over the compiler. All of these methods have equivalent methods on
SelectInstBase. I just want to leave them for a later commit so that this commit
stays small.
Swift SVN r24159
clients of CaptureKind by having getDeclCaptureKind map address-only lets onto
Box or NoEscape, instead of having all the clients do it.
Swift SVN r24136
- Introduce a new 'noescape' CaptureKind and have getDeclCaptureKind()
use it for by-address captures in noescape closures.
- Lower NoEscape captures to a simple inout pointer instead of to a
pointer + refcount.
This includes a test of the SILGen produced code itself along with an
integration test that shows that this enables inout deshadowing to remove
shadows that would otherwise have to be preserved due to closures capturing
them.
This can be more aggressive for address-only let constants, but that will
wait for a follow-up patch.
Swift SVN r24135
It uses a worklist-based algorithm. In contrast to a recursive traversal algorithm,
it cannot cause a stack overflow for very deep dominator trees.
Swift SVN r24107
