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
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
around in the deserializer's .
1,2d
1i
Bump the reference count of a SILFunction as long as it's sitting
around in the deserializer's cache.
If we deserialize a function, then delete it, then deserialize
another reference to it, we'll end up pointing to a deleted
function. This was causing the bug where IRGen would assert
with "no order number for SIL function definition?"; I can't
seem to find a radar for that, though.
Also, deserialization test cases are hard to write and probably
inherently unstable.
Swift SVN r15908
Edge SILFunction one step closer to independence from SILFunctionType context by taking the generic param list as a separate constructor parameter, and serializing those params alongside the function record. For now we still pass in the context params from the SILFunctionType in most cases, because the logic for finding the generic params tends to be entangled in type lowering, but this pushes the problem up a step.
Thanks Jordan for helping work out the serialization changes needed.
Compared to r13036, this version of the patch includes the decls_block RecordKind enumerators for the GENERIC_PARAM_LIST layouts in the sil_block RecordKind enumerator, as Jordan had suggested before. r13036 caused buildbot failures when building for iOS, but I am unable to reproduce those failures locally now.
Swift SVN r13485
Edge SILFunction one step closer to independence from SILFunctionType context by taking the generic param list as a separate constructor parameter, and serializing those params alongside the function record. For now we still pass in the context params from the SILFunctionType in most cases, because the logic for finding the generic params tends to be entangled in type lowering, but this pushes the problem up a step.
Thanks Jordan for helping work out the serialization changes needed.
Swift SVN r13036
In general, this forces SILGen and IRGen code that's grabbing
a declaration to state whether it's doing so to define it.
Change SIL serialization to serialize the linkage of functions
and global variables, which means also serializing declarations.
Change the deserializer to use this stored linkage, even when
only deserializing a declaration, and to call a callback to
inform the client that it has deserialized a new entity.
Take advantage of that callback in the linking pass to alter
the deserialized linkage as appropriate for the fact that we
imported the declaration. This computation should really take
advantage of the relationship between modules, but currently
it does not.
Swift SVN r12090
For now, steal the context generic params from the SILFunctionType, and borrow ArchetypeBuilder's implementation of mapTypeInContext for AST decl contexts. This should eventually be an independent property.
Swift SVN r11811
If there's no script-mode file in a module, don't produce a top_level_code SILFunction for it, and don't consider emitting an LLVM global_ctor for it. We should never emit static constructors from user code anymore.
Swift SVN r11644
Ideally this wouldn't be necessary, but the type substitution APIs required by generic specialization and SIL verification currently require a Module* pointer, and it's obnoxious to have to pass it down separately everywhere it's needed. Longer-term the reliance on Modules for type substitution might be able to go away.
Swift SVN r9866
SILFunction that it references. Use this in the mandatory inlining
pass to remove deserialized transparent functions, to clean up the
-emit-sil output of the compiler (and presumably speed up compile
time). This implements rdar://15272652
Swift SVN r9699
Make ApplyInst and PartialApplyInst directly take substitutions for generic functions instead of trying to stage out substitutions separately. The legacy reasons for doing this are gone.
Swift SVN r8747
Only print function member declarations and skip the bodies since the bodies are already represented in SIL and ASTPrinter is not good enough to print arbitrary expressions.
In order to have valid output, make sure that ASTPrinter does not print references to DynamicLookup protocol.
Swift SVN r8627
Add a SILLinkage mode "Deserialized" to make sure IRGen will emit
hidden symbols for deserialized SILFunction.
Inside SIL linker, set Linkage to external if we only have a declaration for
a callee function.
Both sil block and decl block in a module can emit an array of substitutions.
To share the serialization between SILSerializer and Serializer, we modify
the interface to pass in the abbreviation codes to write functions and to
pass in a cursor to read functions.
We now correctly handle the serialization of Substitutions in SpecializeInst.
For a deserialized SILFunction, we now temporarily set its SILLocation and
DebugScope to an empty FileLocation. Once mandatory inliner sets the SILLocation
to the location of ApplyInst, a null SILLocation and a null DebugScope
may work for a deserialized SILFunction.
Update testing cases to reflect that we are now inlining transparent functions
from modules, or to disable SILDeserializer for now (I am not sure how to update
those testing cases).
Swift SVN r8582
AnyFunctionRef is a universal function reference that can wrap all AST nodes
that represent functions and exposes a common interface to them. Use it in two
places in SIL where CapturingExpr was used previously.
AnyFunctionRef allows further simplifications in other places, but these will
be done separately.
Swift SVN r8239
Lazily-generated currying thunks will require the same IR-level linkonce_odr linkage as clang thunks currently do, so generalize the name of the existing SIL-level linkage specifier 'clang_thunk'.
Swift SVN r8122
Among other things this enables mangled names for tuples.
This adds a pointer to the DeclContext to SILFunction and which is used
to provide the necessary context to the Mangler.
Fixes rdar://problem/14808764 and rdar://problem/14813658.
Swift SVN r8070
functions should be serialized.
Transparent is added as a 1-bit field. In SILGen, we set SILFunction's
transparent attribute according to the attribute of the ValueDecl.
Swift SVN r7882
Added a -v(verbose) option to swift that will trigger verbose printing in SIL
Printer. SIL Printer will print the location info only in the verbose mode.
Here is the example of the format - only the line and colon are displayed for
brevity:
%24 = apply %13(%22) : $[cc(method), thin] ((), [byref] Bool) -> Builtin.Int1 // user: %26 line:46:10
(This will be used to test the validity of SILLocation info.)
Swift SVN r6991
