Still no implementation yet; we'll need to renovate how boxes work a bit to make them projectable (and renovate SILGen to generate typed boxes for the insn to be useful).
Swift SVN r29475
Unfortunately, we still have non-determinism coming from elsewhere, so we
can't start trying to test this yet.
Motivated by rdar://problem/20539158
Swift SVN r28576
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Preparation to fix <rdar://problem/18151694> Add Builtin.checkUnique
to avoid lost Array copies.
This adds the following new builtins:
isUnique : <T> (inout T[?]) -> Int1
isUniqueOrPinned : <T> (inout T[?]) -> Int1
These builtins take an inout object reference and return a
boolean. Passing the reference inout forces the optimizer to preserve
a retain distinct from what’s required to maintain lifetime for any of
the reference's source-level copies, because the called function is
allowed to replace the reference, thereby releasing the referent.
Before this change, the API entry points for uniqueness checking
already took an inout reference. However, after full inlining, it was
possible for two source-level variables that reference the same object
to appear to be the same variable from the optimizer's perspective
because an address to the variable was longer taken at the point of
checking uniqueness. Consequently the optimizer could remove
"redundant" copies which were actually needed to implement
copy-on-write semantics. With a builtin, the variable whose reference
is being checked for uniqueness appears mutable at the level of an
individual SIL instruction.
The kind of reference count checking that Builtin.isUnique performs
depends on the argument type:
- Native object types are directly checked by reading the
strong reference count:
(Builtin.NativeObject, known native class reference)
- Objective-C object types require an additional check that the
dynamic object type uses native swift reference counting:
(Builtin.UnknownObject, unknown class reference, class existential)
- Bridged object types allow the dymanic object type check to be
bypassed based on the pointer encoding:
(Builtin.BridgeObject)
Any of the above types may also be wrapped in an optional. If the
static argument type is optional, then a null check is also performed.
Thus, isUnique only returns true for non-null, native swift object
references with a strong reference count of one.
isUniqueOrPinned has the same semantics as isUnique except that it
also returns true if the object is marked pinned regardless of the
reference count. This allows for simultaneous non-structural
modification of multiple subobjects.
In some cases, the standard library can dynamically determine that it
has a native reference even though the static type is a bridge or
unknown object. Unsafe variants of the builtin are available to allow
the additional pointer bit mask and dynamic class lookup to be
bypassed in these cases:
isUnique_native : <T> (inout T[?]) -> Int1
isUniqueOrPinned_native : <T> (inout T[?]) -> Int1
These builtins perform an implicit cast to NativeObject before
checking uniqueness. There’s no way at SIL level to cast the address
of a reference, so we need to encapsulate this operation as part of
the builtin.
Swift SVN r27887
reference to something of class type. This is required to model
RebindSelfInConstructorExpr correctly to DI, since in the class case,
self.init and super.init *take* a value out of class box so that it
can pass the +1 value without performing an extra retain. Nothing
else in the compiler uninitializes a DI-controlled memory object
like this, so nothing else needs this. DI really doesn't like something
going from initialized to uninitialized.
Yes, I feel super-gross about this and am really unhappy about it. I
may end up reverting this if I can find an alternate solution to this
problem.
Swift SVN r27525
threaded into IRGen; tests to follow when that's done.
I made a preliminary effort to make the inliner do the
right thing with try_apply, but otherwise tried to avoid
touching the optimizer any more than was required by the
removal of ApplyInstBase.
Swift SVN r26747
We no longer need or use it since we can always refer to the same bit on
the applied function when deciding whether to inline during mandatory
inlining.
Resolves rdar://problem/19478366.
Swift SVN r26534
Primarily, unique normal protocol conformances and reference them via
a conformance ID. This eliminates the use of trailing records for
normal protocol conformances and (more importantly) the cases were we
would write incomplete conformances. The latter could cause problems
if we ever ended up deserializing an incomplete conformance without
also deserializing a complete record for that same conformance.
Secondarily, simplify the way we write conformances. They are now
always trailing records, and we separate out the derived conformance
kinds (specialized/inherited) from either a reference to a normal
conformance in the current module file (via a normal conformance ID)
or via a cross-reference to a conformance in another module file
(currently always a normal conformance, but this need not always be
the case). As part of this, make each conformance record
self-sustaining, so we don't have to push information down to the
reading routines (e.g., the conforming type) to actually produce a
proper conformance. This simplifies deserialization logic further.
Swift SVN r26482
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
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
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
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
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
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
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
This is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
Modeling builtins as first-class function values doesn't really make sense because there's no real function value to emit, and modeling them this way complicates passes that work with builtins because they have to invent function types for builtin invocations. It's much more straightforward to have a single instruction that references the builtin by ID, along with the type information for the necessary values, type parameters, and results, so add a new "builtin" instruction that directly represents a builtin invocation. NFC yet.
Swift SVN r22690
layouts. Introduce new SIL instructions to initialize
and open existential metatype values.
Don't actually, y'know, lift any of the restriction on
existential metatypes; just pointlessly burn extra
memory storing them.
Swift SVN r22592
We serialize shared_external linkage as shared since:
1. shared_external linkage is just a hack to tell the optimizer that a
shared function was deserialized.
2. We can not just serialize a declaration to a shared_external function
since shared_external functions still have linkonce_odr linkage at the LLVM
level. This means they must be defined not just declared.
Swift SVN r22562
I can't actually reproduce the buildbot failure that happened last night, so
hopefully it will (a) happen again, so I can investigate, or (b) not happen
again.
Swift SVN r22230
FixNum.h and BCRecordLayout.h will move down into LLVM, APINotes
will move into Clang. Get the namespaces right before we start to move
files around.
Swift SVN r22218
Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
