Using an anonymous union in KeyPathPatternComponent instead of the weird void * in SetterAndIdKind
Added TupleElement kind to KeyPathComponentKindEncoding
Written basic SIL keypath serialization tests
Deleted or edited some old Swift-level tuple key path tests
It does not take ownership of its non-trivial arguments, is a trivial
function type and therefore must not be destroyed. The compiler must
make sure to extend the lifetime of non-trivial arguments beyond the
last use of the closure.
%objc = copy_value %0 : $AnObject
%closure = partial_apply [stack] [callee_guaranteed] %16(%obj) : $@convention(thin) (@guaranteed AnObject) -> ()
%closure2 = mark_dependence %closure : $@noescape @callee_guaranteed () -> () on %obj : $AnObject
%user = function_ref @useClosure : $@convention(thin) (@noescape @callee_guaranteed () -> ()) -> ()
apply %user(%closure2) : $@convention(thin) (@noescape @callee_guaranteed () -> ()) -> ()
dealloc_stack %closure : $() ->()
destroy_value %obj : $AnObject // noescape closure does not take ownership
SR-904
rdar://35590578
Now that we don't store requirements in the GenericParamList, there's
no reason to use trailing records to list out the
GenericTypeParamDecls.
No functionality change.
The functionality change in this commit is that the control block in a
swiftdoc file is validated rather than just being ignored. Tests in
following commit.
This means that:
1. SILGenPattern always borrows the object before it emits a case.
2. Any cast with this cast has a +0 result.
NOTE: That one can not use this with address types (so we assert if you
pass this checked_cast_addr_br).
NOTE: Once we have opaque values, checked_cast_br of a guaranteed value will
lower to a copy + checked_cast_addr_br (assuming the operation is a consuming
cast). To make sure this does not become a problem in terms of performance, we
will need a pass that can transform SILGenPattern +0 cases to +1 cases. This is
something that we have talked about in the past and I think it is reasonable to
implement.
This is an incremental commit towards fixing SILGenPattern for ownership.
rdar://29791263
SILWitnessTable::Entry already contains a superset of what was supported
by SILDefaultWitnessTable::Entry, the latter of which only had “no entry”
and “method” states. Make SILDefaultWitnessTable::Entry an alias for
SILWitnessTable::Entry, and unify all of the parsing/printing/
(de)serialization logic.
ConvertFunction and reabstraction thunks need this attribute. Otherwise,
there is no way to identify that withoutActuallyEscaping was used
to explicitly perform a conversion.
The destination of a [without_actually_escaping] conversion always has
an escaping function type. The source may have either an escaping or
@noescape function type. The conversion itself may be a nop, and there
is nothing distinctive about it. The thing that is special about these
conversions is that the source function type may have unboxed
captures. i.e. they have @inout_aliasable parameters. Exclusivity
requires that the compiler enforce a SIL data flow invariant that
nonescaping closures with unboxed captures can never be stored or
passed as an @escaping function argument. Adding this attribute allows
the compiler to enforce the invariant in general with an escape hatch
for withoutActuallyEscaping.
print and parse as a stable hexadecimal form that isn't interpreted as UTF8.
One use case is in representing serialized protobuf strings (as in the
tensorflow branch: f7ed452eba/lib/SILOptimizer/Mandatory/TFPartition.cpp (L3875)).
The original work was done by @lattner and merged into the tensorflow
branch. This PR is to upstream those changes.
The other side of #17404. Since we don't want to generate up front key path metadata for properties/subscripts with no withheld implementation details, the client should generate a key path component that can be used to represent a key path component based on its public interface.
Signature optimization is slightly different to (most) other thunks, in that
it's taking an existing function and turning that into a thunk, rather than
creating a thunk that calls an existing function. These symbols can be public,
etc. and so need to be handled a bit different to other types of thunks.
Client code can make a best effort at emitting a key path referencing a property with its publicly exposed API, which in the common case will match what the defining module would produce as the canonical key path component representation of the declaration. We can reduce the code size impact of these descriptors by not emitting them when there's no hidden or possibly-resiliently-changed-in-the-past information about a storage declaration, having the property descriptor symbol reference a sentinel value telling client key paths to use their definition of the key path component.
This flag supports promoting KeyPath access violations to an error in
Swift 4+, while building the standard library in Swift 3 mode. This is
only necessary as long as the standard library continues to build in
Swift 3 mode. Once the standard library build migrates, it can all be
ripped out.
<rdar://problem/40115738> [Exclusivity] Enforce Keypath access as an error, not a warning in 4.2.
Add serialization layouts for rare instructions that take extra attributes. We
can continue adding bits to these layout without affecting the layout of the
vast majority of instructions.
This is mostly intended to be used for testing at this point; in the
long run, we want to be using availability information to decide
whether to weak-link something or not. You'll notice a bunch of FIXMEs
in the test case that we may not need now, but will probably need to
handle in the future.
Groundwork for doing backward-deployment execution tests.
This is going to be used for "always emit into client" functions,
such as default argument generators and stored property
initializers.
- In dead function elimination, these functions behave identically to
public functions, serving as "anchors" for the mark-and-sweep
analysis.
- There is no external variant of this linkage, because external
declarations can use HiddenExternal linkage -- the definition should
always be emitted by another translation unit in the same Swift
module.
- When deserialized, they receive shared linkage, because we want the
linker to coalesce multiple copies of the same deserialized
definition if it was deserialized from multiple translation units
in the same Swift module.
- When IRGen emits a definition with this linkage, it receives the
same LLVM-level linkage as a hidden definition, ensuring it does not
have a public entry point.
For now these are underscored attributes, i.e. compiler internal attributes:
@_optimize(speed)
@_optimize(size)
@_optimize(none)
Those attributes override the command-line specified optimization mode for a specific function.
The @_optimize(none) attribute is equivalent to the already existing @_semantics("optimize.sil.never") attribute
The number was limited to 3 attributes for some reason. Now a SILFunction may have up to 2^16 such attributes, which should be enough for a while ;-)
Fixes rdar://problem/34026325
Consider a class hierarchy like the following:
class Base {
func m1() {}
func m2() {}
}
class Derived : Base {
override func m2() {}
func m3() {}
}
The SIL vtable for 'Derived' now records that the entry for m1
is inherited, the entry for m2 is an override, and the entry
for m3 is a new entry:
sil_vtable Derived {
#Base.m1!1: (Base) -> () -> () : _T01a4BaseC2m1yyF [inherited]
#Base.m2!1: (Base) -> () -> () : _T01a7DerivedC2m2yyF [override]
#Derived.m3!1: (Derived) -> () -> () : _T01a7DerivedC2m3yyF
}
This additional information will allow IRGen to emit the vtable
for Derived resiliently, without referencing the symbol for
the inherited method m1() directly.
Also, add a third [serializable] state for functions whose bodies we
*can* serialize, but only do so if they're referenced from another
serialized function.
This will be used for bodies synthesized for imported definitions,
such as init(rawValue:), etc, and various thunks, but for now this
change is NFC.
to correctly handle generalized protocol requirements.
The major missing pieces here are that the conformance search
algorithms in both the AST (type substitution) and IRGen
(witness table reference emission) need to be rewritten to
back-track requirement sources, and the AST needs to actually
represent this stuff in NormalProtocolConformances instead
of just doing ???.
The new generality isn't tested yet; I'm looking into that,
but I wanted to get the abstractions in place first.
For this we need to store the linkage of the “original” method implementation in the vtable.
Otherwise DeadFunctionElimination thinks that the method implementation is not public but private (which is the linkage of the thunk).
The big part of this change is to extend SILVTable to store the linkage (+ serialization, printing, etc.).
fixes rdar://problem/29841635
Teach the serialization of SIL generic environments, which used to be
a trailing record following the SIL function definition, to use the
same uniqued "generic environment IDs" that are used for the AST
generic environments. Many of them overlap anyway, and SIL functions
tend to have AST generic environments anyway.
This approach guarantees that the AST + SIL deserialization provide
the same uniqueness of generic environments present prior to
serialization.
The reason we are using the parsing heuristic is to ensure that we do
not need to update a ton of test cases. This makes sense since in
general, when parsing we are creating new code that is running for the
first time through the compiler. On the other hand, in
serialization/deserialization we expect to get back exactly the
SILFunction that we serialized. So it makes sense to explicitly
preserve whether we have ownership qualification or not.
rdar://28851920
RequirementReprs stored serialized references to archetypes,
which do not have enough information to reconstruct same-type
requirements.
For this reason, we would serialize the 'as written' requirement
string as well as the actual types, which is a horrible hack.
Now that the ASTPrinter and SourceKit use GenericSignatures,
none of this is needed anymore.
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 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.
