with user code and that the boilerplate is counted towards the prologue.
<rdar://problem/18563763> Setting a breakpoint on "main" in a Swift program doesn't stop at user code
Swift SVN r22611
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
For top level function decls, even if their SILFunctions are emitted, we still
print them. They are needed to satisfy protocol requirements.
Swift SVN r22586
the debug scope of each instruction to be the debug scope of the new
function.
This will be tested by the functionality in function signature opts.
Swift SVN r22553
Since both shared and shared_external both lower to linkonce_odr, neither of
them can be declarations. This commit puts a check into the verifier to ensure
that this does not happen at the SIL level allowing us to catch such issues
earlier.
Swift SVN r22552
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
The information in the primary archetype map was redundant with what is
stored in the potential archetypes map and the potential archetypes
themselves.
Swift SVN r22502
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 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
properties.
The main design change here is that, rather than having
purportedly orthogonal storage kinds and has-addressor
bits, I've merged them into an exhaustive enum of the
possibilities. I've also split the observing storage kind
into stored-observing and inherited-observing cases, which
is possible to do in the parser because the latter are
always marked 'override' and the former aren't. This
should lead to much better consideration for inheriting
observers, which were otherwise very easy to forget about.
It also gives us much better recovery when override checking
fails before we can identify the overridden declaration;
previously, we would end up spuriously considering the
override to be a stored property despite the user's
clearly expressed intent.
Swift SVN r22381
constructor in SILBasicBlock::createArgument.
By default the argument is nullptr so any place that currently does not
need to pass in the ValueDecl will not need to be updated given the new
behavior.
Swift SVN r22379
SILFunction::hasSelfArgument() returns true if the SILFunction has a
calling convention with self.
SILArgument::isSelf() returns true if the SILArgument is the last
argument of the first BB of a function for which
SILFunction::hasSelfArgument() is true.
Swift SVN r22378
This will be used for parsing sil generated from stdlib. We will ignore
the AST decls and instead import them from the module.
rdar://17979145
Swift SVN r22367
This prevented dead function removal of inlined dead functions. Beside the stdlib it's mostly
an issue of SIL size (and therefore compiletime), because llvm did remove such functions anyway.
Swift SVN r22301
Addressors now appear to pass a simple smoke-test; in
order to allow some parallel developement, I'll be
committing actual SILGen tests for this later and
separately.
Swift SVN r22243
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
Use this in calls to TypeBase::getTypeOfMember() that were relying on
archetypes solely because they were using EnumElementDecl::getArgumentType().
Swift SVN r22205
The metatype is associated with the formal AST type of the value, not whatever lowered SIL type we happen to have lying around. Adjust the SIL verifier to check that value_metatype instructions produce a metatype for which the instance is a potential lowering rather than by exact type match. This lets us take the metatype of metatypes (and incidentally, of functions, and of tuples thereof), fixing rdar://problem/17242770.
Swift SVN r22202
