Changes from previous version:
* Support classes
* Support protocols and generics
* Make the obvious extensions to cover assignment operator pairs
Swift SVN r23954
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
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
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
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
"array.props.isCocoa/needsElementTypeCheck" semantic calls will mark calls that
return array properties: isCocoa and needsElementTypeCheck. We know that said
states can only transfer in certain directions (a native swift array that does
not need an element type check stays in this state) enabling us to version loops
based on the state of said array array properties.
rdar://17955309
Swift SVN r23688
References to functions that take inout parameters crash the compiler
because InOutType isn't a "real" type in itself and has no special type
metadata to emit. It merely further qualifies the function's input
types.
For example, we would like to have a unique entry in the cache for:
var f: (T, T) -> ()
and
var f2: (inout T, T) -> ()
For each argument type metadata pointer in the function's input, take
advantage of pointer alignment and mark the lowest bit if it is inout.
Since the metadata cache uses pointers to create the key, this creates a
unique entry while still being able to extract the actual pointer.
This fixes <rdar://problem/17655125>, and a couple of other similar
crashes.
Swift SVN r23557
The main change here is a total restructuring of the
unspecified behavior rule. (Note that the rule has not
changed; I'm simply specifying it differently, hopefully
better.)
I still owe some examples for the unspecified behavior rule.
Swift SVN r23344
We want to use the reserved space in the metadata pattern for protocol conformance caching, and this link lets us find the metadata pattern from an instance of the generic type.
Swift SVN r22898
This reverts commit r22829, because reverting r22828 depends on it.
Reverting r22828 because it
was apparently causing an assertion on the bot:
Swift SVN r22830
terminators"
This is an assumption that the SSAUpdater makes. Verify that we preserve this
property.
With changes to the test cases, SIL documentation and add a critical edge (non
cond_br only) splitting pass to the mandatory pipeline.
This reapplies commit 22775.
Swift SVN r22803
