storage for arbitrary values.
A buffer doesn't provide any way to identify the type of
value it stores, and so it cannot be copied, moved, or
destroyed independently; thus it's not available as a
first-class type in Swift, which is why I've labelled
it Unsafe. But it does allow an efficient means of
opaquely preserving information between two cooperating
functions. This will be useful for the adjustments I
need to make to materializeForSet to support safe
addressors.
I considered making this a SIL type category instead,
like $@value_buffer T. This is an attractive idea because
it's generally better-typed. The disadvantages are that:
- it would need its own address_to_pointer equivalents and
- alloc_stack doesn't know what type will be stored in
any particular buffer, so there still needs to be
something opaque.
This representation is a bit gross, but it'll do.
Swift SVN r23903
The underlying problem is that e.g. even if a method is private but its class is public, the method can be referenced from another module - from the vtable of a derived class.
So far we handled this by setting the SILLinkage of such methods according to the visibility of the class. But this prevented dead method elimination.
Now I set the SILLinkage according to the visibility of the method. This enables dead method elimination, but it requires the following:
1) Still set the linkage in llvm so that it can be referenced from outside.
2) If the method is dead and eliminated, create a stub for it (which calls swift_reportMissingMethod).
Swift SVN r23889
as passing self by value, not by inout. This is the correct representation at
the AST level, and we now lower self references as the new @in_guaranteed
parameter convention. This allows SIL clients (like DI) to know that a nonmutating
protocol method does not mutate the pointee passed into the method.
This fixes:
<rdar://problem/19215313> let properties don't work with protocol method dispatch
<rdar://problem/15821762> Self argument of generic curried nonmutating instance methods is inout
Swift SVN r23864
It avoids generation of llvm phi nodes with identical predecessors and differing values.
This change replaces my previous fix of this problem in r23580, where I handled it in IRGen.
There were some discussions about it with the conclusion that it's better to just disallow such cond_br instructions in SIL.
It makes the life easier for some SIL optimizations which can't deal with cond_br with identical destinations.
The original radar is <rdar://problem/18568272> Swift compiler fails with "PHI node has multiple entries for the same basic block with different incoming values!"
Swift SVN r23861
Now all SIL function specialization passes use the new mangling infrastructure.
Lets keep it that way for future passes as well. = ).
Implements:
<rdar://problem/18831609>
Fixes:
<rdar://problem/19065735>
<rdar://problem/18906781>
<rdar://problem/18956916>
Swift SVN r23859
isn't used yet, but will be for modeling the self argument passed to an
address-only witness implementation. NFC since all this code is dead :-)
Swift SVN r23857
Using the intrinsics is obnoxious because I needed them
to return Builtin.NativeObject?, but there's no reasonable
way to safely generate optional types from Builtins.cpp.
Ugh.
Dave and I also decided that there's no need for
swift_tryPin to allow a null object.
Swift SVN r23824
This is apart of creating the infrastructure for creating special manglings for
all of the passes that we specialize. The main motiviations for this
infrastructure is:
1. Create an easy method with examples on how to create these manglings.
2. Support multiple specializations. This is important once we allow for partial
specialization and can already occur if we perform function signature
optimizations on specialized functions.
The overall scheme is as follows:
_TTS<MANGLINGINFO>__<FUNCNAME>
Thus if we specialize twice, the first specialization will just be treated as
the function name for the second specialization.
<MANGLINGINFO> is defined as:
_<SPECIALIZATIONKINDID>_<SPECIALIZATIONUNIQUEINFO>
Where specialization kind is an enum that specifies the specific sort of
specialization we are performing and specialization unique info is enough
information to ensure that the identity of the function is appropriately
preserved.
Swift SVN r23801
They're invalid, and we don't want to blow the stack trying to decompose a type with infinite elements. Fixes rdar://problem/17920535.
Swift SVN r23775
Add the following functionality to the Swift compiler:
* covariant subtyping of Set
* upcasting, downcasting of Set
* automatic bridging between Set and NSSet, including
* NSSet params/return values in ObjC are imported as Set<NSObject>
* Set params/return values in Swift are visible to ObjC as NSSet
<rdar://problem/18853078> Implement Set<T> up and downcasting
Swift SVN r23751
SILMetadata is the base class with a single enum member (MDKind).
SILBranchNode is the derived class with additional members:
unsigned NumOperands
an array of uint32_t
A static member function SILBranchNode::get is implemented to get or create
SILBranchNode. All SILMetadata created are uniqued and saved in SILModule's
member variable:
llvm::FoldingSet<SILMetadata> Metadatas
Usage of SILMetadta by SILInstruction is captured in SILModule's member variable:
llvm::DenseMap<const SILInstruction *, SILMetadata *> MetadataStore
This is similar to LLVM's Metadata. Another option is to add a SILMetadata* to
SILInstruction. The disadvantage is the waste of space when we don't have PGO on.
This commit also enables parsing and printing of SILMetadata.
We add keyword sil_metadata to define SILMetadata:
sil_metadata !0 = {"branch_weights", 3, 5}
For parsing, we add a map in SILModule
llvm::DenseMap<unsigned, SILMetadata *> NumberedMetadata
that maps from ID to SILMetadata* to help matching usage of "!id" in SILFunction
with definition of "!id" in sil_metadata section.
For printing, we assign IDs to SILMetadata at SILModule scope, we then pass in
an optional argument of
llvm::DenseMap<const SILMetadata *, unsigned> *MetadataMap
to SILFunction::print in order to get the ID of SILMetadata used in
SILInstruction.
Post-commit review will be appreciated.
rdar://18269754
Swift SVN r23713
or pointer depends on another for validity in a
non-obvious way.
Also, document some basic value-propagation rules
based roughly on the optimization rules for ARC.
Swift SVN r23695
Verify that witness_method instructions with a lookup type that is an
opened archetype have the optional operand that represents the
open_existential instruction.
I ran into this working supporting substitution of existential types in
mandatory inlining (rdar://problem/17769717).
Swift SVN r23665
This does not have any tests since I am going to start going through SILGen
tests and updating them for guaranteed self as the appropriate tests.
*NOTE* There is more work to be done in terms of thunks, but the basic
functionality is done.
rdar://15729033
Swift SVN r23653
This should have been done a long time ago since SILOptions are options that
should be able to effect everything SIL related. In this case I just want to
pass in a flag on the SILModule to enable +0 self. By putting it on the
SILModule I can conveniently check it in SILFunctionType without exposing any
internal state from SILFunctionType.cpp.
Swift SVN r23647
This cleans up the code and removes the circular dependency in between handling
the self parameter and computing the number of arguments. Previously we were
handling this by separately computing the number of parameters twice. This
ensures that we only use the real param count after we lower all of the
arguments helping to avoid any possibility of a bug arising due to the two
methods of computing the number of parameters differing.
This does not have any changes to SILGen output since it is just a refactoring.
This also makes it very easy to change the self parameter convention to
guaranteed by just changing the convention returned by the default swift
convention (the reason why I am making this change).
Swift SVN r23621
A "Projection Tree" takes in a type and constructs a tree where each non-leaf
node represents an aggregate that can be split up and all leaf nodes represent a
subtype of the original type that we can not split.
It additionally provides the capability to propagate usage information
and liveness information through the tree, making it trivial to perform
SROA + partial dead use elimination. I am using this in function
signature opts for that purpose.
Swift SVN r23586
It's not always correct to map a Swift Bool back to ObjCBool in C land, since Bool could have originally been a proper _Bool. Pass the clang::Decl down to type lowering so we can recognize this. We still don't have a great solution for block types, because there's no decl to refer to, and Swift's user-level type system erases the distinction between void(^)(_Bool) and void(^)(BOOL). However, this is enough to let us start using C APIs that traffic in _Bool.
Swift SVN r23546
Specifically, a qualified lookup can now be treated as:
- a known private dependency, which does not affect downstream files
- a known non-private dependency, which may affect downstream files
- a known non-dependency
- unknown, which means the compiler will try to infer whether it's a
private dependency from the context
This commit also includes some obvious uses of the new flags, but nothing
actually too interesting yet; there shouldn't be any observable behavior
change here in normal user code.
Swift SVN r23483
This can arise by substitution when we specialize a generic parameter bounded by an ObjC protocol with an ObjC protocol type. Fixes rdar://problem/19035529.
Swift SVN r23463
And fix some bugs with existential conformances, where we were creating a bogus conformance instead of just using null conformances like other code expects.
Swift SVN r23461
This API didn't take accessibility into account in a useful way, and
usually did a more general search than what was actually needed. We've
gradually been replacing uses of it with either more safe or more direct
APIs, including a regular UnqualifiedLookup, DeclContext::lookupQualified,
or Module::lookupValue. Now it's gone.
No functionality change.
Swift SVN r23449
Before this patch there was no dependence visible to the optimizer between a
open_existential and the witness_method allowing the optimizer to reorder the
two instruction. The dependence was implicit in the opened archetype but this
is not a concept model by the SIL optimizer.
%2 = open_existential %0 : $*FooProto to $*@opened("...") FooProto
%3 = witness_method $@opened("...") FooProto,
#FooProto.bar!1 : $@cc(...)
%4 = apply %3<...>(%2)
This patch changes the SIL representation such that witness_methods on opened
archetypes take the open_existential (or the producer of the opened existential)
as an operand preventing the optimizer from reordering them.
%2 = open_existential %0 : $*FooProto to $*@opened("...") FooProto
%3 = witness_method $@opened("...") FooProto,
#FooProto.bar!1,
%2 : $*@opened("...") FooProto : $@cc(...)
%4 = apply %3<...>(%2)
rdar://18984526
Swift SVN r23438
I want to cleanup some code paths in SILCombine and LoadStoreOpts to use
generic create{Addr,Value}Projection methods which create the
appropriate projection instruction for a Projection method. Also this
will allow me to start to hide more of the internal state of Projection.
Swift SVN r23366
This changes the Projection API so that you pass in an instruction and get back
an optional depending on what theinstruction was. This is much cleaner than
always needing to do a switch.
This commit also cleans up the naming in Projection so that we always use the
term "value projection" for struct_extract, tuple_extract, and
unchecked_enum_data instead of the term "extract". This lines up better with the
name we use for the *_addr instructions, "address projection" and avoids
ambiguity since unchecked_enum_data does not have the word "extract" in it.
Additionally by adding in the failable initializers, my centralization of the
initialization logic enables me to ensure that isAddrProjection and
isValueProjection stay in sync with the various constructors via asserts. This
should prevent future bugs if we add additional notions of "projection".
Swift SVN r23356
This is apart of some cleanups of the Projection class.
I also improved the comment at the top of projection to make its usage
clearer.
Swift SVN r23355
Note that I did not change any actual memory behavior. That will come via a
later cleanup phase. Since this is a correctness fix I wanted to only make
things more conservative.
rdar://18568601
Swift SVN r23311
