Per the previous commit we are no longer using this. Minor save in
simplicity and maybe a bit of compilation time as well.
In the long run IRGen probably shouldn't be pulling information from the
AST at all; the SILModule should be able to tell it what types it needs
to emit information for. But this is still an improvement for now.
No functionality change (that was the previous commit).
Swift SVN r24840
Instead, just fall through to the normal public/internal/private switch
added in the previous commit. Local declarations are always private.
Make sure we emit all local declarations by using the list in the SourceFile,
rather than walking the AST (which missed a few cases and was less efficient
anyway).
As an exception, declarations without accessibility at all still get private
linkage. These are things like local variables that don't get accessed by
symbol, even when using the debugger.
rdar://problem/19623016
Swift SVN r24839
The underlying problem is that e.g. even if a method is private but its class is public, the method can be referenced from another module - from the vtable of a derived class.
So far we handled this by setting the SILLinkage of such methods according to the visibility of the class. But this prevented dead method elimination.
Now I set the SILLinkage according to the visibility of the method. This enables dead method elimination, but it requires the following:
1) Still set the linkage in llvm so that it can be referenced from outside.
2) If the method is dead and eliminated, create a stub for it (which calls swift_reportMissingMethod).
Swift SVN r23889
This works by loading the protocols from a specially named symbol,
which is generated by the linker through the help of a linker script
that merges all of the protocol conformance blocks into one section
with its size at the start of it and points a global symbol at
the section.
We do all this because unlike MachO, section information does not
survive to be loaded into memory with ELF binaries. Instead,
the mappings that survive are 'segments', which contain one or
more sections. Information about how these relate to their original
sections is difficult, if not impossible, to obtain at runtime.
Swift SVN r23518
This works by loading the protocols from a specially named symbol,
which is generated by the linker through the help of a linker script
that merges all of the protocol conformance blocks into one section
with its size at the start of it and points a global symbol at
the section.
We do all this because unlike MachO, section information does not
survive to be loaded into memory with ELF binaries. Instead,
the mappings that survive are 'segments', which contain one or
more sections. Information about how these relate to their original
sections is difficult, if not impossible, to obtain at runtime.
Swift SVN r23475
Just injecting a new protocol descriptor into an already-running ObjC runtime isn't a good idea, since the runtime might have already canonized the protocol somewhere else, and it won't recognize that classes conform to protocols it doesn't know about.
Swift SVN r23313
We lazily realize classes when we access their metadata now, so there's no need to force the ObjC runtime to do this greedily anymore, except for classes that the runtime statically references. For those cases, add an @objc_non_lazy_realization class attribute that will put that class reference in the nlclslist section.
Swift SVN r23105
Move the uniquing information for ForeignTypeMetadata behind the address point so we can share the layout between foreign classes and the existing layout for struct and enum metadata. Emit metadata records for imported structs and enums as foreign metadata candidates, and dynamically unique references to the metadata by calling swift_getForeignTypeMetadata.
Swift SVN r23081
With runtime conformance lookup, it isn't possible without more complex analysis to determine whether a witness table is needed at runtime. In particular, in whole-module mode, it looked like no protocol conformances in the test/Interpreter/protocol_lookup.swift test were used, causing all of the tests to fail in -i mode. Erik's been working on SIL-level dead witness elimination which will hopefully offset the compile time hit here.
Swift SVN r23067
When we emit a witness table, build a protocol conformance record for it, and emit the list of all conformance records into a "__swift1_proto" section of the data segment.
Swift SVN r22939
We used to make fragile PrivateExternal and HiddenExternal symbols
'hidden' in LLVM. While this seems to work on Mach-O, ELF linkers can
not satisfy a hidden not defined symbol with a default symbol from a
shared library.
Swift SVN r22696
Eliminate the intermediate top_level_code function. Now that SIL is expressive enough to express a "main" function, there's no reason for it, and this eliminates a bunch of mystery code in IRGen to thunk from main to top_level_code by reaching for hardcoded symbol names. Demystify the special code for setting up C_ARGC and C_ARGV by having SILGen look for a transparent "_didEnterMain" hook in the stdlib and emit a call to it.
Swift SVN r22525
This is controlled by a new isWholeModule() attribute in SILModule.
It gives about 9% code size reduction on the benchmark executables.
For test-suite reasons it is currently not done for the stdlib.
Swift SVN r22491
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
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 off by default and is a modified version of r21996 (reverted in r22001).
Update SILGlobalOpt to remove "once" call from addressor and set the
InitializerF for SILGlboalVariable if legal.
For calls to addressor in non-cold block, we check the addressor to find out
the globalinit_func and the associated SILGlobalVariable. If legal, we set
InitializerF of SILGlobalVariable and remove "once" call from addressor.
The current rules for legality:
1> the addressor contains a single "once" call and it calls globalinit_func.
2> the globalinit_func is called by "once" from a single location.
When we inline the addressor, the globalinit_func will be called by "once"
from multiple locations. After we remove the "once" from the addressor, the
inlined version will mistakely initialize the global variable again.
3> the globalinit_func is trivial as defined by
SILGlobalVariable::canBeStaticInitializer().
Update IRGen to generate constant initializers for global variables with static
initializers (i.e non-null InitializerF).
Joe's suggestion on having the static initializer to return the result instead
of storing it is not implemented in this commit. But we do verify that a static
initializer has a single store to the global variable. The suggestion is tracked
in rdar://18382039.
Implement rdar://16621368, rdar://18169093.
Swift SVN r22083
LLDB has been setting 'Playground' for their REPL mode too to get some of
these behaviors, but that's not something we want to do long-term, and it's
already been subtly wrong in a few cases. Now 'Playground' really does mean
playgrounds, and 'DebuggerSupport' means REPL /or/ LLDB expression parser
mode.
rdar://problem/18338200
Swift SVN r22030
r21996 tries to take advantage of LLVM global opt that eliminates global
initializers by using llvm.global_ctors. Revert it because we can't guarantee
that they will be optimized to constant initializers.
A modifed version will follow that uses constant initializers directly in IRGen.
Swift SVN r22001
Update SILGlobalOpt to remove "once" call from addressor and set the
InitializerF for SILGlboalVariable if legal.
For calls to addressor in non-cold block, we check the addressor to find out
the globalinit_func and the associated SILGlobalVariable. If legal, we set
InitializerF of SILGlobalVariable and remove "once" call from addressor.
The current rules for legality:
1> the addressor contains a single "once" call
2> it calls globalinit_func
3> the globalinit_func is called by "once" from a single location
4> the globalinit_func is trivial
Update IRGen to emit llvm.global_ctors for global variables with static
initializers (i.e non-null InitializerF).
Performance --------
After:
Totals,54,67202,67202,67202,0,0 Onone
Totals,54,88948,88948,88948,0,0 O
Totals,54,71222,71222,71222,0,0 Ounchecked
Totals,54,66405,66405,66405,0,0 Onone
Totals,54,88759,88759,88759,0,0 O
Totals,54,71761,71761,71761,0,0 Ounchecked
Before:
Totals,55,68133,68133,68133,0,0 Onone
Totals,55,92458,92458,92458,0,0 O
Totals,55,72262,72262,72262,0,0 Ounchecked
Totals,55,69022,69022,69022,0,0 Onone
Totals,55,92178,92178,92178,0,0 O
Totals,55,72593,72593,72593,0,0 Ounchecked
Swift SVN r21996
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
...so that they don't get dead-stripped out of an executable...
...so that they can be accessed by unit tests (or in-process plug-ins).
In Swift, marking something 'public' is a deliberate action (unlike in C),
so anything marked 'public' should be left in the final binary...even when
we're building an executable.
We currently /also/ mark the symbols for internal and private decls as
external as well, so they also won't be stripped. Hopefully that will
change soon.
rdar://problem/18173029
Swift SVN r21815
If a type has to be passed or returned resiliently, it
will necessarily be passed indirectly, which is already
represented in SILFunctionType. There is no need to
represent this as a separate channel of information.
NFC. Also fixes a problem where the signature cache
for ExtraData::Block was writing past the end of an
array (but into the storage for an adjacent array
which was fortunately never used).
ExtraData should also disappear as a concept, but we're
still relying on that for existential protocol witnesses.
Swift SVN r21548
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
Also, use 'Playground' to control the behavior of ignored expressions
(which are not an error because they are displayed in the playground log).
This is preparation for LLDB no longer passing 'DebuggerSupport' for a
playground <rdar://problem/18090611>. 'DebuggerSupport' now only applies
to REPL-like contexts and enables identifiers beginning with $, special
rules for parsing top-level code, ignored expressions (like playgrounds),
and the @LLDBDebuggerSupport attribute.
Besides ignored expressions, 'Playground' enables the playground transformation
and provides an entry point for debugger initialization.
Note that this is a bit insincere---many of the options controlled by both
'Playground' and 'DebuggerSupport' really only apply to the main source file
or main module. If/when we add back support for source file imports, we'll
need to revisit all of LangOptions and see which of them should /really/
apply to /everything/ in the ASTContext.
Swift SVN r21384
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 is a simple, trivialy, not-even-half-way-there solution to weak
leaking of Objective-C classes introduced after the deployment
target. It only works for Objective-C classes and C global variables
that Clang consideres to be "weak imported". However, this bare
minimum should be enough to develop an app (by jumping through various
hoops) that uses new functionality when its
available. <rdar://problem/17296490>, which I've restricted in scope
to capture this.
Swift SVN r20956
functions, and make those functions memoize the result.
This memoization can be both threadsafe and extremely
fast because of the memory ordering rules of the platforms
we're targeting: x86 is very permissive, and ARM has a
very convenient address-dependence rule which happens to
exactly match the semantics we need.
Swift SVN r20381
*NOTE* This linkage is different from {Public,Hidden}External in that it has no
extra semantic meaning beyond shared.
The use of this linkage is to ensure that we do not serialize deserialized
shared functions. Those shared functions can always be re-deserialized from the
original module. This prevents a whole class of bugs related to the
creation of module cross references since all references to the shared
item go straight to the original module.
<rdar://problem/17772847>
Swift SVN r20375
