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.
If the concrete type is an existential or a generic type, we should not perform the optimization, because we don’t know enough information about it.
Fixes rdar://31372306
Till now createApply, createTryApply, createPartialApply were taking some arguments like SubstCalleeType or ResultType. But these arguments are redundant and can be easily derived from other arguments of these functions. There is no need to put the burden of their computation on the clients of these APIs.
The removal of these redundant parameters simplifies the APIs and reduces the possibility of providing mismatched types by clients, which often happened in the past.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
This bug occurs in real projects, when type aliases are involved.
The test-case is a bit hard to provide. I’ll try to provide it later, if I managed to reduce the original project to a small test-case.
But the fix is very obvious.
Fixes rdar://31768258
