The reason to do this is:
1. The check in SILInliner if we can inline can be done without triggering
side-effects.
2. This enables us to know if inlining will succeed before attempting to inline.
This enables for arguments to be adjusted with new SILInstructions and the like
before inlining occurs. I use this in a forthcoming patch that updates mandatory
inlining for ownership.
rdar://31521023
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
This commit contains:
-) adding the new instructions + infrastructure, like parsing, printing, etc.
-) support in IRGen to generate global object-variables (i.e. "heap" objects) which are statically initialized in the data section.
-) IRGen for global_value which lazily initializes the object header and returns a reference to the object.
For details see the documentation of the new instructions in SIL.rst.
Remove the cast consumption kind from all unconditional casts. It
doesn't make sense for unconditional casts, complicates SIL ownership,
and wasn't fully supported for all variants. Copies should be
explicit.
Count how many generic specializations were prevented due to the possibility of creating an infinite generic specialization loop and due to the complexity of their generic type parameters.
Allow for cases, where the old substitution type `T1` is partially contained in the new substitution type `T2`. Partially contained means that if you drop the common structural "prefix" of `T1` and `T2` and get `T1'` and `T2'` then `T1'` is strictly contained in `T2'`. E.g. `Outer<Start>` is partially contained in `Outer<Step<Start>>` if you drop the common prefix `Outer`, then `Start` is contained in `Step<Start>`
The existing simple mechanism for avoiding infinite generic specialization loops is based on checking the structural depth and width of types passed as generic type parameters. If the depth or the width of a type is above a certain threshold, the type is considered too complex for generic specialization and no specialization is produced. While this approach prevents the possibility of producing an infinite number of generic specializations for ever-growing generic type parameters, it catches the issue too late in some cases, leading to excessive CPU and memory usage.
Therefore, the new method tries to solve the problem at its root. An infinite generic specialization loop can be triggered by specializing a given generic call-site if and only if:
- Doing so would result in a loop inside the specialization graph represented by the `GenericSpecializationInformations`, i.e. it would produce direct or indirect recursion involving a generic call
- The substitutions used by the current generic call-site are structurally more complex than the substitutions used by the same call-site in the previous iteration inside specialization graph. More complex in this context means that the new generic type parameter structurally contains the generic type parameter from a previous iteration inside the specialization graph and has greater structural depth, e.g. `Array<Int>` is more complex than `Int`.
The generic specializer now records all the required information about specializations it produces and uses it later to detect and prevent any generic specializations which would result in an infinite specialization loop. It detects them as early as possible and thus reduces compile times, memory consumption and potentially also reduces the code-size by not generating useless specializations.
Since the return type of the callee is not changed and the old apply instruction is not removed by devirtualizeClassMethod, there is no need to insert an "unreachable" instruction, because by construction rules of SIL it should be already there right after the old apply.
This bug was caught by the SIL verifier. Any invocation of a NoReturn function should be followed by an `unreachable` instruction.
Fixes rdar://problem/33591235
In dead-array elimination we assume that the array allocation is post-dominated by all its final releases.
The only exception are branches to dead-end ("unreachable") blocks. So we just ignored all paths which didn't end up in a final release.
Now we explicitly pass the set of dead-end blocks and just ignore those blocks.
This is safer and it's also needed in the upcoming re-write of StackPromotion.
This has the same semantics as open_existential_box, but returns an object value
instead of an address.
This is used in SIL opaque values mode. Attempting to reuse open_existential_box
in this mode causes SIL type inconsistencies that are too difficult to work
around. Adding this instruction allows for consistent handling of opaque values.
The original versions of several of these currently redundant instructions will
be removed once the SIL representation stabilizes.
These instructions have the same semantics as the *ExistentialAddr instructions
but operate directly on the existential value, not its address.
This is in preparation for adding ExistentialBoxValue instructions.
The previous name would cause impossible confusion with "opaque existentials"
and "opaque existential boxes".
@_semantics(inline_late) for inlining only outside the standard library in the
late performance inliner.
It can be beneficial to run the inliner only outside the standard library when
code size has been reduced far enough that inlining can take place based on the
inliner's heuristics.
rdar://33099675
SR-5360
partial_apply is a confusing instruction since it:
1. Is printed with a function signature.
2. Takes in some arguments of the same type as the underlying types of the given function signatures.
3. Always takes in those arguments at +1 regardless of the convention printed on the partial apply.
Eventually we will split the partial apply representation so that the box is
represnted explicitly separately from the function signature, eliminating this
confusion.
The problem that we ran into here is that we were not treating @in values from
an alloc_stack or @in_guaranteed at all correctly. The reason why the tests did
not catch this is that a seperate sil_combine optimization that eliminates
trivially dead live ranges was eliminting the alloc_stack of the @in value in
our test. In contrast, the @in_guaranteed case was actually never tested at all.
I added tests for all of these conventions and in addition added a special mode
to SILCombine that stops the alloc_stack eliminating during testing.
rdar://32887993
Specifically, do not perform the early inlining for functions annotated with @_semantics("pair_no_escaping_closure") and @_semantics("self_no_escaping_closure")
Add new tests and cleanup some tests.
It recovers from the performance regression that was recently introduced.
Fixes rdar://32555803
This peephole is to avoid runtime calls:
unconditional_checked_cast_addr T in %0 : $*T to P in %1 : $*P
->
%addr = init_existential_addr %1 : $*P, T
copy_addr %0 to %addr
where T is a type statically known to conform to non-class existential P.
In caase P is a class existential type, it generates:
%val = load %0 : $*T
%existential = init_existential_ref %val : $T, $T, P
store %existential to %1 : $*P
Either the demangling completely succeeds or it fails. Don't demangle to something like: [...] with unmangled suffix "..."
This avoids getting really stupid demangled names for symbols which are actually not swift symbols.
If there is a conditional bridged cast from a swift type to an objc type and this cast happens in two stages, where:
- in the firs stage the Swift type is casted to its bridged ObjC class (e.g. String to NSString) and
- in the second stage there is a downcast to a subclass of a bridged ObjC class (e.g. NSString to MyString)
then the second stage should use a conditional cast.
rdar://32319580
If some functions are explicitly annotated by developers as @inline(__always) or @_transparent, they should always be a subject for the inlining of generics, even if this kind of inlining is not enabled currently for all functions.
If some functions are explicitly annotated by developers as @inline(__always) or @_transparent, they should always be a subject for the inlining of generics, even if this kind of inlining is not enabled currently for all functions.
The GenericSignatureBuilder requires `finalize()` to be called before a
generic signature can be retrieved with `getGenericSignature()`. Most of the former isn’t strictly needed unless you want a generic signature, and the
latter is potentially expensive. `computeGenericSignature()` combines the two
operations together, since they are conceptually related. Update most of the
callers to the former two functions to use `computeGenericSignature()`.
A function is pure if it has no side-effects.
If there is a call of a pure function with constant arguments, it always makes sense to inline it, because we know that the whole computation will be constant folded.
When casting from an object type to a bridged Swift value type, classifyDynamicCast would use the cast classification for the target type's bridged object type, which would be trivially WillSucceed for thinks like NSNumber-to-Int or NSError-to-SomeError, even though the bridging itself could fail. Fixing this fixes SR-2920|rdar://problem/31404281.
