@noescape function types will eventually be trivial. A
convert_escape_to_noescape instruction does not take ownership of its
operand. It is a projection to the trivial value carried by the closure
-- both context and implementation function viewed as a trivial value.
A safe SIL program must ensure that the object that the project value is based
on is live beyond the last use of the trivial value. This will be
achieve by means of making the lifetimes dependent.
For example:
%e = partial_apply [callee_guaranteed] %f(%z) : $@convention(thin) (Builtin.Int64) -> ()
%n = convert_escape_to_noescape %e : $@callee_guaranteed () -> () to $@noescape @callee_guaranteed () -> ()
%n2 = mark_dependence %n : $@noescape @callee_guaranteed () -> () on %e : $@callee_guaranteed () -> ()
%f2 = function_ref @use : $@convention(thin) (@noescape @callee_guaranteed () -> ()) -> ()
apply %f2(%n2) : $@convention(thin) (@noescape @callee_guaranteed () -> ()) -> ()
release_value %e : $@callee_guaranteed () -> ()
Note: This is not yet actually used.
Part of:
SR-5441
rdar://36116691
Create helpers in InstructionUtils.h wherever we need a guarantee that the diagnostics cover the same patterns as the verifier. Eventually this will be called from both SILVerifier and the diagnostic pass:
- findAccessedAddressBase
- isPossibleFormalAccessBase
- isPartialApplyOfReabstractionThunk
- findClosureForAppliedArg
- visitAccessedAddress
Add partial_apply verification assert.
This applies the normal "find a closure" logic inside the "find all partial_apply uses" verification. Making the verifier round-trip ensures that we don't have holes in exclusivity enforcement related to this logic.
* Implement #warning and #error
* Fix #warning/#error in switch statements
* Fix AST printing for #warning/#error
* Add to test case
* Add extra handling to ParseDeclPoundDiagnostic
* fix dumping
* Consume the right paren even in the failure case
* Diagnose extra tokens on the same line after a diagnostic directive
Use `unsigned` instead of `bool` for the member to make all members of
the structure the same. This fixes the behaviour of the structure on
Windows. The difference in the type caused the bitfields to be pushed
to the natural alignment of int resulting in the structure being padded
to 12-bytes instead of being packed into 4. Using `#pragma pack` also
did not make a difference here as the structure remained padded to
12-bytes.
i.e for:
enum Indirect<T> {
indirect cast payload(first: T, second :T)
}
let _ = Indirect<X>
The payload's SIL box type will be:
$<t_0_0> { var (first: t_0_0, second: t_0_0) } <X>
rdar: //36799330
The thunking code we have for introducing runtime nil checks in thunks when an optional-to-non conversion appears in contravariant position doesn't handle blocks. This somehow-worked in previous versions of Swift (maybe due to assertions being off). Spot fix for rdar://problem/36843476.
Now we will consistently expand destroy_addr/copy_addr into either
{retain,release}_value or into ARC operations on its most derived descendents.
This will improve code-size (by not expanding when we didn't intend to), but
more importantly preserve invariants that the ARC optimizer depends upon.
rdar://36509461
This enum controls how certain routines in TypeLowering potentially expand types
when performing copy_value/destroy_value operations. Its previous form was
problematic because:
1. The name LoweringStyle does't suggest anything related to expansion really.
The new has the word expansion in it explicitly.
2. The cases of LoweringStyle used to be Shallow, Deep. This caused confusion
since Shallow (the base case) was not a no-op. It just caused us to expand into
children. Now TypeExpansionKind has 3 cases to make this clear: None,
DirectChildren, and MostDerivedDescendents.
Confusion around this API caused us to canonicalize ARC operations differently
for different operations (e.g. copy_value/destroy_value vs
copy_addr/destroy_addr). This caused us to misout on some code-size wins (since
we were splitting some operations onto DirectChildren of aggregates), but more
importantly also caused the optimizer to break an invariant that the ARC
optimizer relied upon: local semantic pairings being at the same level of
abstraction. In a subsequent commit, I am going to fix that bug.
rdar://36509461
- Clear the 'serialized' flag on witness tables and vtables
after serialization, not just functions. This fixes SIL
verifier failures if post-serialization SIL is printed
out and parsed back in.
- Clear the 'serialized' flag when deserializing functions,
witness tables and vtables in a module that has already
been serialized. This fixes SIL verifier failures if
we deserialize more declarations after serializing SIL.
We were seeing SIL verifier failures on bots that run the
tests with the stdlib built with non-standard flags.
Unfortunately I don't have a reduced test case that would
fail in PR testing without these fixes.
Fixes <rdar://problem/36682929>.
Extend witness tables with a pointer to the protocol conformance
descriptor from which the witness table was generated. This will allow
us to determine (for example) whether two witness tables were
generated from the same (or equivalent) conformances in the future, as
well as discover more information about the witness table itself.
Fixes rdar://problem/36287959.
For the majority of artificial helper functions the filename is
actively misleading since it usually represents the file of the caller
that triggered the helper to be generated. Instead, this patch creates
a virtual filname `<compiler-generated>` to make it very obvious that
the function has not correspondence to any source code.
<rdar://problem/33809560>
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.
Another cleanup before I add a new SILLinkage kind.
This operation is difficult to reason about and was only used by
the SIL verifier. Replace the SIL verifier checks with simpler
operations.
I still need to revisit and uncomment the default witness table
visibility check. Right now we serialize default witness tables,
but default witness thunks have private linkage, which is
clearly wrong.
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
This is an ABI-dependent routine, so at least should have ABI in the name. In
the future, the compiler may introduce new ABI layout rules for select types
based on the deployment target. Code like this needs to be reviewed at that time.
Clarify the comments.
This is a step towards being able to report coverage for closures in
member initializer expressions. These closures do not inherit a
profiler, so they need a fresh one.
We currently treat initializer expressions which aren't closures as a
part of the constructor. This doesn't work for closures because the
constructor's profiler may not be available at the time the closure is
created.
This patch moves the ownership of profiling state from SILGenProfiling
to SILFunction, where it always belonged. Similarly, it moves ownership
of the profile reader from SILGenModule to SILModule.
The refactor sets us up to fix a few outstanding code coverage bugs and
does away with sad hacks like ProfilerRAII. It also allows us to locally
guarantee that a profile counter increment actually corresponds to the
SILFunction at hand.
That local guarantee causes a bugfix to accidentally fall out of this
refactor: we now set up the profiling state for delayed functions
correctly. Previously, we would set up a ProfilerRAII for the delayed
function, but its counter increment would never be emitted :(. This fix
constitutes the only functional change in this patch -- the rest is NFC.
As a follow-up, I plan on removing some dead code in the profiling
logic and fixing a few naming inconsistencies. I've left that for later
to keep this patch simple.
This patch moves the ownership of profiling state from SILGenProfiling
to SILFunction, where it always belonged. Similarly, it moves ownership
of the profile reader from SILGenModule to SILModule.
The refactor sets us up to fix a few outstanding code coverage bugs and
does away with sad hacks like ProfilerRAII. It also allows us to locally
guarantee that a profile counter increment actually corresponds to the
SILFunction at hand.
That local guarantee causes a bugfix to accidentally fall out of this
refactor: we now set up the profiling state for delayed functions
correctly. Previously, we would set up a ProfilerRAII for the delayed
function, but its counter increment would never be emitted :(. This fix
constitutes the only functional change in this patch -- the rest is NFC.
As a follow-up, I plan on removing some dead code in the profiling
logic and fixing a few naming inconsistencies. I've left that for later
to keep this patch simple.
Make getDesugaredType() as fast as possible for now. With the old way:
1) Switching over the sugared types turned into a frequently
mispredicted branch because the sugar in the type system is random
as far as the processor is concerned.
2) Storing the underlying/singlely-desugared type at different offsets
in memory adds more code bloat and misprediction.
Short of a major redesign to avoid pointer chasing, this is probably as
fast as the method will get.
* Reduce array abstraction on apple platforms dealing with literals
Part of the ongoing quest to reduce swift array literal abstraction
penalties: make the SIL optimizer able to eliminate bridging overhead
when dealing with array literals.
Introduce a new classify_bridge_object SIL instruction to handle the
logic of extracting platform specific bits from a Builtin.BridgeObject
value that indicate whether it contains a ObjC tagged pointer object,
or a normal ObjC object. This allows the SIL optimizer to eliminate
these, which allows constant folding a ton of code. On the example
added to test/SILOptimizer/static_arrays.swift, this results in 4x
less SIL code, and also leads to a lot more commonality between linux
and apple platform codegen when passing an array literal.
This also introduces a couple of SIL combines for patterns that occur
in the array literal passing case.
* Implement a few silcombine transformations for arrays
- Useless existential_ref <-> class conversions.
- mark_dependence_inst depending on uninteresting instructions.
- release(init_existential_ref(x)) -> release(x) when hasOneUse(x)
- Update COWArrayOpt to handle the new forms generated by this.
these aren't massive performance wins, but do shrink the size of SIL when
dealing with arrays.
* Generalize testcase to work on linux and on mac when checking stdlib is enabled.
1) Remove SWIFT_INLINE_BITS boilerplate. Now that we're not using anonymous/transparent unions, we don't need the
SWIFT_BITFIELD_BITS macro.
2) Refine the the bitfield size check to better support templated bitfields.
3) Refine the SIL templated bitfields to not be prematurely "full".
