This was already done for getSuccessorBlocks() to distinguish getting successor
blocks from getting the full list of SILSuccessors via getSuccessors(). This
commit just makes all of the successor/predecessor code follow that naming
convention.
Some examples:
getSingleSuccessor() => getSingleSuccessorBlock().
isSuccessor() => isSuccessorBlock().
getPreds() => getPredecessorBlocks().
Really, IMO, we should consider renaming SILSuccessor to a more verbose name so
that it is clear that it is more of an internal detail of SILBasicBlock's
implementation rather than something that one should consider as apart of one's
mental model of the IR when one really wants to be thinking about predecessor
and successor blocks. But that is not what this commit is trying to change, it
is just trying to eliminate a bit of technical debt by making the naming
conventions here consistent.
Before this commit all code relating to handling arguments in SILBasicBlock had
somewhere in the name BB. This is redundant given that the class's name is
already SILBasicBlock. This commit drops those names.
Some examples:
getBBArg() => getArgument()
BBArgList => ArgumentList
bbarg_begin() => args_begin()
This ensures that we can write FileCheck patterns that match the end of sil
functions. Just using a FileCheck pattern against a brace is not sufficient in
the context of checking the SIL emitted by SILGen. This is because we could match a
different function's body and match the closing brace against the other
function's end brace.
With this change, one can be specific by checking:
// CHECK: } {{.*}} end sil function '<mangled name>'
The inspiration for this change is rdar://28685236. While updating SILGen tests
for that I have found many instances of SILGen tests pattern matching against
the wrong function bodies. This change will allow me to eliminate these problems
robustly.
rdar://29077869
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
This is a cleanup for SILParsing/Printing. I verified that everything was
spelled correctly by taking the current parsing switch moving that into a file,
regenerating it using the .def file and then diffed them. The diff was the same.
rdar://28685236
Sugared GenericTypeParamTypes point to GenericTypeParamDecls,
allowing the name of the parameter as written by the user to be
recovered. Canonical GenericTypeParamTypes on the other hand
only store a depth and index, without referencing the original
declaration.
When printing SIL, we wish to output the original generic parameter
names, even though SIL only uses canonical types. Previously,
we used to accomplish this by mapping the generic parameter to an
archetype and printing the name of the archetype. This was not
adequate if multiple generic parameters mapped to the same
archetype, or if a generic parameter was mapped to a concrete type.
The new approach preserves the original sugared types in the
GenericEnvironment, adding a new GenericEnvironment::getSugaredType()
method.
There are also some other assorted simplifications made possible
by this.
Unfortunately this makes GenericEnvironments use a bit more memory,
however I have more improvements coming that will offset the gains,
in addition to making substitution lists smaller also.
This lets us get to the goal of +0 guaranteed closure contexts. NFC yet, just add the under-the-hood ability for partial_apply instructions producing callee-guaranteed closures to be parsed, printed, and serialized.
It's the same thing as for alloc_ref: the optional [tail_elems ...] attribute specify the tail elements to allocate.
For details see docs/SIL.rst
This feature is needed so that we can allocate a MangedBuffer with alloc_ref_dynamic.
The ManagedBuffer.create() function uses the dynamic self type to create the buffer instance.
The new instructions are: ref_tail_addr, tail_addr and a new attribute [ tail_elems ] for alloc_ref.
For details see docs/SIL.rst
As these new instructions are not generated so far, this is a NFC.
The new instructions are: ref_tail_addr, tail_addr and a new attribute [ tail_elems ] for alloc_ref.
For details see docs/SIL.rst
As these new instructions are not generated so far, this is a NFC.
This patch is rather large, since it was hard to make this change
incrementally, but most of the changes are mechanical.
Now that we have a lighter-weight data structure in the AST for mapping
interface types to archetypes and vice versa, use that in SIL instead of
a GenericParamList.
This means that when serializing a SILFunction body, we no longer need to
serialize references to archetypes from other modules.
Several methods used for forming substitutions can now be moved from
GenericParamList to GenericEnvironment.
Also, GenericParamList::cloneWithOuterParameters() and
GenericParamList::getEmpty() can now go away, since they were only used
when SILGen-ing witness thunks.
Finally, when printing generic parameters with identical names, the
SIL printer used to number them from highest depth to lowest, by
walking generic parameter lists starting with the innermost one.
Now, ambiguous generic parameters are numbered from lowest depth
to highest, by walking the generic signature, which means test
output in one of the SILGen tests has changed.
This establishes a real def-use relation from the self-parameter to any instruction which uses the dynamic-self type.
This is an addition to what was already done for opened archetypes.
The biggest part of this commit is to rename "OpenedArchetypeOperands" to "TypeDependentOperands" as this name is now more appropriate.
Other than that the change includes:
*) type-dependent operands are now printed after a SIL instruction in a comment as "type-defs:" (for debugging)
*) FuncationSignatureOpts doesn't need to explicitly check if a function doesn't bind dynamic self to remove a dead self metadata argument
*) the check if a function binds dynamic self (used in the inliner) is much simpler now
*) also collect type-dependent operands for ApplyInstBase::SubstCalleeType and not only in the substitution list
*) with this SILInstruction::mayHaveOpenedArchetypeOperands (used in CSE) is not needed anymore and removed
*) add type dependent operands to dynamic_method instruction
Regarding the generated code it should be a NFC.
When DynamicSelfType occurs outside of a class body (for example,
inside of a SIL function), it is not enough to simply utter 'Self',
because then we lose the underlying type.
Instead, print it out as '@dynamic_self Foo', where 'Foo' is the
underlying class type or archetype, and add parser support for
the same.
Fixes <rdar://problem/27735857>.
Previously, if a generic type had a stored property with
a generic type and an initializer expression, we would
emit the expression directly in the body of each designated
initializer.
This is a problem if the designated initializer is defined
within an extension (even in the same source file), because
extensions have a different set of generic parameters and
archetypes.
Also, we've had bugs in the past where emitting an
expression multiple times didn't work properly. While these
might currently all be fixed, this is a tricky case to test
and it would be best to avoid it.
Fix both problems by emitting the initializer expression
inside its own function at the SIL level, and call the
initializer function from each designated initializer.
I'm using the existing 'variable initializer' mangling for this;
it doesn't seem to be used for anything else right now.
Currently, the default memberwise initializer does not use
this, because the machinery for emitting it is somewhat
duplicated and separate from the initializer expressions in
user-defined constructors. I'll clean this up in an upcoming
patch.
Fixes <https://bugs.swift.org/browse/SR-488>.
Adds a "[clang <value_decl>]" attribute to a SIL function declaration for clang imported functions.
SIL serialization already handled this attribute, but not the SIL parser.
Fixes rdar://problem/27378249, SR-2089
This was done some time ago to make it easier to diff large amounts of SIL
output. The problem is that it makes it difficult to know the *true* memory
order that the predecessor list is in which can lead to surprise when working
with SIL and create test cases.
I believe some time after that point we added the notion of "sorted" sil, i.e.
SIL that does not guarantee any relation to the actual memory representation of
the SIL and is meant to ease diffing. This fits nicely with the true intention
of this sort of sorting.
Thus this commit puts sorting PredIDs, UserIDs behind that flag.
In Swift, default arguments are associated with a function or
initializer's declaration---not with its type. This was not always the
case, and TupleType's ability to store a default argument kind is a
messy holdover from those dark times.
Eliminate the default argument kind from TupleType, which involves
migrating a few more clients over to declaration-centric handling of
default arguments. Doing so is usually a bug-fix anyway: without the
declaration, one didn't really have
The SILGen test changes are due to a name-mangling fix that fell out
of this change: a tuple type is mangled differently than a non-tuple
type, and having a default argument would make the parameter list of a
single-parameter function into a tuple type. Hence,
func foo(x: Int = 5)
would get a different mangling from
func foo(x: Int)
even though we didn't actually allow overloading.
Fixes rdar://problem/24016341, and helps us along the way to SE-0111
(removing the significance of argument labels) because argument labels
are also declaration-centric, and need the same information.
Strict aliasing only applies to memory operations that use strict
addresses. The optimizer needs to be aware of this flag. Uses of raw
addresses should not have their address substituted with a strict
address.
Also add Builtin.LoadRaw which will be used by raw pointer loads.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
Now that ObjC types can be generic, we need to satisfy the type system by plumbing pseudogeneric parameters through func-to-block invocation thunks. Fixes rdar://problem/26524763.
This was mistakenly reverted in an attempt to fix buildbots.
Unfortunately it's now smashed into one commit.
---
Introduce @_specialize(<type list>) internal attribute.
This attribute can be attached to generic functions. The attribute's
arguments must be a list of concrete types to be substituted in the
function's generic signature. Any number of specializations may be
associated with a generic function.
This attribute provides a hint to the compiler. At -O, the compiler
will generate the specified specializations and emit calls to the
specialized code in the original generic function guarded by type
checks.
The current attribute is designed to be an internal tool for
performance experimentation. It does not affect the language or
API. This work may be extended in the future to add user-visible
attributes that do provide API guarantees and/or direct dispatch to
specialized code.
This attribute works on any generic function: a freestanding function
with generic type parameters, a nongeneric method declared in a
generic class, a generic method in a nongeneric class or a generic
method in a generic class. A function's generic signature is a
concatenation of the generic context and the function's own generic
type parameters.
e.g.
struct S<T> {
var x: T
@_specialize(Int, Float)
mutating func exchangeSecond<U>(u: U, _ t: T) -> (U, T) {
x = t
return (u, x)
}
}
// Substitutes: <T, U> with <Int, Float> producing:
// S<Int>::exchangeSecond<Float>(u: Float, t: Int) -> (Float, Int)
---
[SILOptimizer] Introduce an eager-specializer pass.
This pass finds generic functions with @_specialized attributes and
generates specialized code for the attribute's concrete types. It
inserts type checks and guarded dispatch at the beginning of the
generic function for each specialization. Since we don't currently
expose this attribute as API and don't specialize vtables and witness
tables yet, the only way to reach the specialized code is by calling
the generic function which performs the guarded dispatch.
In the future, we can build on this work in several ways:
- cross module dispatch directly to specialized code
- dynamic dispatch directly to specialized code
- automated specialization based on less specific hints
- partial specialization
- and so on...
I reorganized and refactored the optimizer's generic utilities to
support direct function specialization as opposed to apply
specialization.
