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
This is necessary to be able to properly stash values with nontrivial lowerings, such as metatypes and functions, inside existential containers. Modify SILGen to lower values to the proper abstraction level before storing them in an existential container. Part of the fix for rdar://problem/18189508, though runtime problems still remain when trying to actually dynamicCast out a metatype from an Any container.
Swift SVN r21830
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
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
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
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
These instructions do a bitcast operation without stack traffic (at the SIL level). unchecked_trivial_bit_cast represents a conversion from a potentially nontrivial type to a trivial type, such as from a class reference to Int. unchecked_ref_bit_cast represents a conversion between types for which retain_value and release_value has equivalent effects when applied on the input or output values.
Swift SVN r19053
These types are often useless and confusing to users who expect to be able to use Sequence or Generator as types in their own right like in C# or Java. While we're here, relax the rules for self-conformance to admit methods returning 'Self'. Covariant return types should not actually prevent a protocol type from conforming to itself, and the stdlib makes particular use of protocols with 'init' requirements which implicitly return Self.
Swift SVN r18989
Add objc_metatype_to_object and objc_existential_metatype_to_object to convert metatypes to AnyObject, and objc_protocol to get a reference to an @objc protocol descriptor as a Protocol class instance.
Swift SVN r18824
Float32 and Float64 typealiases
This works around a defect in the type checker, where it loses sugar
from FloatLiteralType while performing type inference for more complex
expressions involving floating point types.
rdar://16770279
Swift SVN r17241
There were a bunch of things broken here--it's amazing this ever appeared to work.
- Retain 'self' before partial_applying it to the method, so we don't overrelease it.
- Correctly lower the ownership conventions of the dynamic method against the SILDeclRef, so we don't overrelease arguments or over-over-release self, and we handle ObjC methods with weird conventions correctly.
- Thunk when there are bridging type differences between the partially-applied ObjC method and a Swift method, so we don't crash if the method takes NSStrings or other bridged types.
Add verifier checks that the result of 'dynamic_method' and BB arg of 'dynamic_method_br' actually match the method they're dispatching.
Swift SVN r17198
r15824 overrode SILVerifier::visitSILBasicBlock without calling up to the super definition, causing us to never actually verify any instructions for the past three weeks. Awesome. Patch up the latent bugs that have crept in, except for three devirtualizer tests that fail. This doesn't reenable the verifier because I don't want to cause crashes until all the regressions have been cleared up.
Swift SVN r17121
An unsafe cast from a base to a derived class isn't really all that different from one from Builtin.NativeObject to an arbitrary class, so relax this pair of instructions to allow an arbitrary bitcast. This only combines the instructions; it doesn't attempt to simplify any codegen that was emitting round-trip casts before yet.
Swift SVN r16736
This allows the payload for a loadable enum to be unsafely projected without branching, enabling more enum optimizations when switch branches can be culled or when indirect enum code can be promoted.
Swift SVN r16729
Give us a way to formally represent autoreleases in SIL separate from autoreleased returns, allowing us to lifetime-extend inner pointer parameters the lazy way and hopefully clean up some asmname hacks in the stdlib implementation too.
Swift SVN r16632
We print the AST type for the member when printing SILDeclRef for
protocol_method and dynamic_method. The AST type can be polymorphic, so parsing
of PolymorphicFunctionType is added to the Parser. Also add parsing "inout"
right before an identifier type. "inout" was parsed only in parseTypeTupleBody.
rdar://15763213
Swift SVN r16460
We want to model block invoke functions as taking the address of their @block_storage directly, so resolve @block_storage as part of type repr resolution, allowing it to appear as a parameter of a SIL function type.
Swift SVN r16370
Add project_block_storage, to project the capture storage from within a block_storage, and init_block_storage_header, to represent filling out the block header.
Swift SVN r16358
Blocks need to be born on the stack, so we need a way to represent that on-stack storage. @block_storage T will represent the layout of a block that contains storage for a capture of type T.
Swift SVN r16355
We won't have any types where copying has an effect on the bit pattern (except for blocks, which need special handling anyway), and copy_value having a result makes optimizations more complex, so remove it.
Swift SVN r15640
When a particular class has no designated initializers explicitly
written or implicitly defined, complain and suggest initializers for
all of the stored properties that need them and appear to have
sensible default values. Fixes <rdar://problem/15670604>.
Swift SVN r15023
The problem is that SILDeclRef::print does not print enough information
for SILParser to find the correct Decl when there are overloading members.
This commit handles the case for class_method. We print type information for
the SILDeclRef together with the SILFunctionType separated by a comma.
SILParser then use the type information to disambiguate the overloaded
methods.
rdar://15763213
Swift SVN r14994
Currently this consists of private functions and shared functions. Even
though shared functions are technically serializable, we only want to
serialize them if their serialization is requested.
Swift SVN r14825
This reverts commit r14623. I will recommit this when I reenable deserialization
of witness tables/vtables. This will enable the deserialization of SILFunctions
by default from the stdlib by avoiding the lack of external witness
tables/vtables.
Swift SVN r14786
This fixes a bug where we were deserializing a function with a call to a shared
linkage function. The shared linkage function was never deserialized causing an
assertion to fire due to shared linkage functions always needing a definition.
I am planning on implementing lazy deserialization of vtable functions.
Swift SVN r14581
