a non-native owner. This is required by Slice, which
will use an ObjC immutable array object as the owner
as long as all the elements are contiguous.
As part of this, I decided it was best to encode the
native requirement in the accessor names. This makes
some of these accessors really long; we can revisit this
if we productize this feature.
Note that pinning addressors still require a native
owner, since pinning as a feature is specific to swift
refcounting.
Swift SVN r24420
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
use a thin function type.
We still need thin-function-to-RawPointer conversions
for generic code, but that's fixable with some sort of
partial_apply_thin_recoverable instruction.
Swift SVN r24364
Teach IRGen and the runtime about the extra inhabitants
of function pointers, and take advantage of that in
thin and thick function types.
Also add runtime entrypoints for thin function type
metadata.
Swift SVN r24346
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
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
