In preparation for the switch to llvm::Optional, which doesn't have this.
I suggested it, but got some pushback from David Blaikie, which is
understandable because implicit conversions are dangerous.
std::experimental::optional also doesn't have this, and we don't use it
too much. The only cost is being slightly more explicit when relying on
conversions to give us a T to then wrap in an Optional.
Swift SVN r22472
In preparation for the switch to llvm::Optional, which doesn't have a 'cache'
method. Given how long we spent bikeshedding over the name and how few places
we ended up using it, I didn't feel like trying to push it through on the
LLVM side.
Swift SVN r22471
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
Update SILGen to create SILGlobalVariable and SILGlobalAddrInst instead of
GlobalAddrInst. When we see a definition for a global variable, we create
the corrsponding SILGlobalVariable definition.
When creating SILGlobalVariable from a global VarDecl, we mangle the global
VarDecl in the same way as we mangle it at IRGen. The SILLinkage is also
set in the same way as we set it at IRGen.
At IRGen, we use the associated VarDecl for SILGlobalVariable if it exists,
to have better debugging information.
We set the initializer for SILGlobalVariable definition only.
We also handle SILGlobalAddrInst in various SILPasses, in the similar way
as we handle GlobalAddrInst.
rdar://15493694
Swift SVN r21887
This will let the performance inliner inline a function even if the costs are too high.
This attribute is only a hint to the inliner.
If the inliner has other good reasons not to inline a function,
it will ignore this attribute. For example if it is a recursive function (which is
currently not supported by the inliner).
Note that setting the inline threshold to 0 does disable performance inlining at all and in
this case also the @inline(__always) has no effect.
Swift SVN r21452
This disables inlining at the SIL level. LLVM inlining is still enabled. We can
use this to expose one function at the SIL level - which can participate in
dominance based optimizations but which is implemented in terms of a cheap check
and an expensive check (function call) that benefits from LLVM's inlining.
Example:
The inline(late) in the example below prevents inlining of the two checks. We
can now perform dominance based optimizations on isClassOrObjExistential.
Without blocking inlining the optimizations would apply to the sizeof check
only and we would have multiple expensive function calls.
@inline(late)
func isClassOrObjExistential(t: Type) -> Bool{
return sizeof(t) == sizeof(AnyObject) &&
swift_isClassOrObjExistential(t)
}
We do want inlining of this function to happen at the LLVM level because the
first check is constant folded away - IRGen replaces sizeof by constants.
rdar://17961249
Swift SVN r21286
Enable SIL parsing and SIL serialization of semantics.
We add one more field to SILFunctionLayout for semantics. We should refactor
handling of attributes at SIL level, right now they are in SILFunction as bool
or std::string and in SIL serializer as a 1-bit field or an ID field.
rdar://17525564
Swift SVN r19434
These types are needed by enough of the stack now that it makes sense to centralize their lookup and caching onto the AST context like other core types.
Swift SVN r19029
Mandatory-inlined (aka transparent functions) are still treated as if they
had the location and scope of the call site. <rdar://problem/14845844>
Support inline scopes once we have an optimizing SIL-based inliner
Patch by Adrian Prantl.
Swift SVN r18835
If a source file contains the main class for its module, then implicitly emit a top_level_code that invokes UIApplicationMain with the name of the marked class.
Swift SVN r18088
This fixes a case where the Swift-variadic and C-varargs versions of
various initializers were superseding each other
<rdar://problem/16801456>.
It also uncovered some more cases where we weren't getting quite the
right semantics for factory-methods-as-initializers, which are also
fixed here.
Swift SVN r18010
Generalize the bridging of AnyObject[] to NSArray into bridging T[] to
NSArray, following what we already have for dictionaries. Use some new
Foundation-level entry points for the bridging, which could use an
audit from someone who understands Array better than I do.
Part of <rdar://problem/16535097>.
Swift SVN r17869
This should be used sparingly , for cases where forming the parameter/result types is tricky due to generics. If we could form those types without too much pain, it'd be better to remove this hack. However, it enables bridging in cases where we need generic bridging.
Swift SVN r17837
This was an artifact of their long-dead C++-based implementations that was way past due to clean up. It's also a convenient workaround for <rdar://problem/16835447>, since we no longer have to look up constructor members for String at SILGen time and potentially lazily instantiate Clang-imported types during SILGen. This totally isn't a real solution to that problem, but it puts out the fire for now.
Swift SVN r17643
This is part of our poor-man's internal compiler SPI hiding
in the standard library. We don't want these functions showing
up in code completion, etc.
Swift SVN r16916
The implied semantics are:
- side-effects can occur any time before the first invocation.
- all calls to the same global_init function have the same side-effects.
- any operation that may observe the initializer's side-effects must be
preceded by a call to the initializer.
This is currently true if the function is an addressor that was lazily
generated from a global variable access. Note that the initialization
function itself does not need this attribute. It is private and only
called within the addressor.
Swift SVN r16683
Before we create a new initializer, check whether it would collide
with existing initializers. If it's better than the existing
initializer, mark the existing one as unavailable; if it's not better,
don't build it.
In support of this, we tweak a few things w.r.t. unavailble
declarations:
- An unavailable declaration is shadowed by an available one,
- Don't emit SIL unavailable, imported initializers
This fixes the last problem with <rdar://problem/16509024>.
Swift SVN r16611
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
Allows AnyObject[] to occur in @objc methods/properties/etc., then
bridges between the two in SILGen based on the new array
implementation. <rdar://problem/16535097>.
Note that this commit does not change the Clang module importer to
import NSArray* as AnyObject[] (yet).
Swift SVN r16004
Make ObjCMutablePointer @objc-able for (potentially optional) class types, and bridge it down to UnsafePointer when calling @objc entry points.
Swift SVN r15838
When we see CConstPointer or CMutablePointer in a foreign function signature, transparently bridge it to UnsafePointer at the foreign entry point, lifetime-extending the C*Pointer value during foreign calls so that its owner reference is held for the duration of the call.
Swift SVN r15602
Add __FUNCTION__ to the repertoire of magic source-location-identifying tokens. Inside a function, it gives the function name; inside a property accessor, it gives the property name; inside special members like 'init', 'subscript', and 'deinit', it gives the keyword name, and at top level, it gives the module name. As a bit of future-proofing, stringify the full DeclName, even though we only ever give declarations simple names currently.
Swift SVN r14710
Inherited initializers are now functional: one can use an inherited
initializer to construct an object of a subclass type, and we properly
handle delegation to overridden complete object or subobject
initializers as appropriate. See the executable test.
This commit also contains various fixes for the IRGen side of vtable
emission and use. Proper IRGen tests still to come.
For now, we're still performing peer delegation from a subobject
initializer to another subobject initializer, hence the SILGen hack
for identifying when we're in a complete object vs. a subobject
initializer. We'll be banning delegation from subobject initializers,
so this hack---along with the peer_method instruction---will be going
away in the near future.
Swift SVN r14571
Emit witnesses for initializer requirements. Allow the use of
initializer requirements on archetypes; existentials don't work due to
<rdar://problem/16165890>.
Swift SVN r14356
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
