Without this if you called either of these methods when you did not have True or
False operands, memory that is not owned by the CondBranchInst would be touched.
Now we just check if we don't have the relevant arguments and early return an
empty array of the relevant type.
Swift SVN r26782
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
The witness calling convention is for dispatching via the witness
table, which is not the case for protocol extensions. At some point,
it might make sense for protocol extensions to use the witness calling
convention, but for now the native method calling convention
suffices.
Swift SVN r26616
This includes:
1. Extract instructions which extracts a trivial part of an aggregate that has
one RCIdentity.
2. Instructions which take a pointer out of ARC's control by converting it to a
trivial type. This is safe to do since we can assume that the object that is
convered is alive when the conversion happens. So assuming that we can
conservatively find all RC users, we will have at least one RC user that
post dominates the use (since otherwise we would be touching a dangling
pointer). We leave it to the user of the pass to determine what is safe to do
with this information. Potentially in the future it might make sense to return
this information as well so that a user can use that information directly.
rdar://20305817
Swift SVN r26583
The new base class ApplyInstBase contains APIs that are common for ApplyInst and PartialApplyInst. It allows such optimization passes like generic specializer to treat both instructions in the same way whenever it is possible. Before this change, one had to duplicate and adjust a lot of implementation code in such passes, because ApplyInst and PartialApplyInst were not related to each other in any form.
The existing clients of both classes can continue using the usual APIs. No changes are required. Only new clients, which want to treat ApplyInst and PartialApplyInst in a uniform way, may do so. One of such new clients is the generic specializer, whose adjusted implementation will be submitted in the following commit.
Swift SVN r26581
Remove the semantic restrictions that prohibited extensions of
protocol types, and start making some systematic changes so that
protocol extensions start to make sense:
- Replace a lot of occurrences of isa<ProtocolDecl> and
dyn_cast<ProtocolDecl> on DeclContexts to use the new
DeclContext::isProtocolOrProtocolExtensionContext(), where we want
that behavior to apply equally to protocols and protocol extensions.
- Eliminate ProtocolDecl::getSelf() in favor of
DeclContext::getProtocolSelf(), which produces the appropriate
generic type parameter for the 'Self' of a protocol or protocol
extension. Update all of the callers of ProtocolDecl::getSelf()
appropriately.
- Update extension validation to appropriately form generic
parameter lists for protocol extensions.
- Methods in protocol extensions always use the witnesscc calling
convention.
At this point, we can type check and SILGen very basic definitions of
protocol extensions with methods that can call protocol requirements,
generic free functions, and other methods within the same protocol
extension.
Regresses four compiler crashers but improves three compiler
crashers... we'll call that "progress"; the four regressions all hit
the same assertion in the constraint system that will likely be
addressed as protocol extensions starts working.
Swift SVN r26579
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
This should clear the way for removing isTransparent on apply entirely.
Previously we marked any apply of an autoclosure transparent, but now
that the mandatory inliner inlines anything marked transparent, we don't
need that.
Resolves rdar://problem/20286251.
Swift SVN r26525
The string version of r26479. There's a lot of backstory and justification
there, so just read that commit message again. The one addition for String
is that global NSString constants are loaded as String as well, so that
also has to go through the bridging code even though there's no function
call involved.
Finishes rdar://problem/19734621.
Swift SVN r26510
...and similar for NSDictionary and NSSet.
For APIs that don't have a reason to distinguish "empty" and "absent" cases,
we encourage standardizing on "empty" and marking the result as non-optional
(or in Objective-C, __nonnull). However, there are system APIs whose
implementations currently do return nil rather than an empty collection
instance. In these cases, we recommend /changing/ the API to return the
appropriate "empty" value instead.
However, this can cause problems for backwards-deployment: while the API is
truly non-optional on system vN, a program may encounter a nil return value
if run on system vN-1. Objective-C can generally deal with this (especially
if the only thing you do is ask for the count or try to iterate over the
collection) but Swift can't. Therefore, we've decided to "play nice" and
accept nil return values for the collection types (NSArray, NSDictionary,
and NSSet) and implicitly treat them as "empty" values if they are the
result of an imported function or method.
Note that the current implementation has a hole regarding subscript getters,
since we still make an AST-level thunk for these in the Clang importer.
We can probably get rid of those these days, but I didn't want to touch
them at this point. It seems unlikely that there will be a subscript that
(a) is for a collection type, and (b) mistakenly returned nil in the past
rather than an empty collection.
There's another hole where an ObjC client calls one of these mistakenly-nil-
returning methods and then immediately hands the result off by calling a
Swift method. However, we have to draw the line somewhere.
(We're actually going to do this for strings as well; coming soon.)
rdar://problem/19734621
Swift SVN r26479
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
This change permits SILGen to make smarter decisions about
block placement by keeping related blocks together instead
of always inserting to the end to the function. The
flipside is that SILGen needs to be somewhat careful to
create blocks in the right order. Counter-intuitively,
that order is the reverse of the order in which the blocks
should be laid out, since blocks created later will be
inserted before blocks created earlier. Note, however,
that this produces the right results for recursive
emission.
To that end, adjust a couple of places in SILGen to
create blocks in properly nested order.
All of the block-order differences in the tests seem
to be desirable; several of them even had confused
comments wondering how on earth a block got injected
where it did.
Also, fix the implementation of SILBuilder::moveBlockTo,
and fix a latent bug in epilogue emission where epilogBB
was erased from its parent (deleting it) and then
queried multiple times (!).
Swift SVN r26428
Getting the protocols of an arbitrary type doesn't make sense, so start phasing this out by introducing specialized entry points that do make sense:
- get the inherited protocols of a ProtocolDecl
- get the conforming protocols for an associated type or generic
type parameter
- (already present) ask for the protocols to which a nominal type conforms
Swift SVN r26411
Before, providing a full SILFunction declaration object with a proper SILType was the only way to link a function. And constructing such a SILFunction declaration by hand using low-level SIL APIs is very annoying and requires a lot of code to be written. This new linkFunction API allows for a lookup using SILDeclRef and essentially performs linking of a SILFunction by its mangled name (assuming this name is unique), which is much easier to invoke. The new API is useful, e.g. when you need to link a well-known function from a standard library.
Swift SVN r26252
This allows types to be lowered as scalar reference-counted types without requiring them to have AST-level reference semantics. For now, put in a staging assertion to ensure isReferenceCounted == hasReferenceSemantics to make sure we set the bit properly everywhere.
Swift SVN r26238
The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
TerminatorInsts. Now you can walk over the successor list of a terminator
and actually modify the SILSuccessor directly, allowing better CFG
transformations. NFC.
Swift SVN r26140
Check if the outcome of a cast from an ObjC type to a Swift type or from a Swift type to an ObjC type can be statically determined.
This allows for folding of many such casts.
Swift SVN r26125
Do not fall through from the metatypes analysis code if the analysis could not decide whether the cast would succeed or fail. Make a more explicit decision instead based on the instance type of a metatype.
This fixes some logical errors in analysis of casts between bridged types. They were caused by falling through from the metatypes analysis.
Swift SVN r26120
sil-verifier was using SIL types to check metatypes. But metatypes, especially metatypes of metatypes, use AST types. Therefore checks should be done based on AST types.
rdar://20153162
Swift SVN r26111
We discussed it with Joe and this requirement does not make sense, especially if casts are produced by one pass, but optimized by another one. Moreover, having equal from and to types is eventually not very efficient, but is not semantically wrong. Such casts can often be produced by the inliner or specialised.
Swift SVN r26110
This makes it easier to diff and read SIL output. Since it is behind the -emit-sorted-sil
flag, there is no effect on normal compilation.
Swift SVN r26101
Give SILType 'getPreferredExistentialRepresentation' and 'canUseExistentialRepresentation' methods, which track what types of container particular existential types may use--fixed-sized, class-constrained, metatype, or box. Allow for existentials to use a specialized representation for certain known concrete types by allowing these methods to take a concrete type. NFC yet, except to replace some ad-hoc verifier conditions with canUseExistentialRepresentation checks where appropriate.
Swift SVN r26062
This can only happen in the closure specializer and the generic
specializer since all other specializations either copy the linkage of
the original function (function signature opts) or clone closures/thunks
which have shared linkage.
I put in a verifier check that makes sure we do not create shared
versions of these functions. The real problem has to do with serializing
these sorts of functions, but since we always serialize shared
functions, it makes sense to just ban it.
rdar://20082696
Swift SVN r26001
This is useful for cleaning-up the code generated by intermediate transformations, e.g. for cases where we perform folding of always failing casts into traps followed by an unreachable instruction. I'll make use of it in my subsequence commits.
Swift SVN r25988
