Have SILGen mark all variables bound from pattern bindings without initializers (and *only* ones without initializers) with mark_uninitialized [var] pseudo instructions. On the DI end, *only* consider mark_uninitialized instructions for DI analysis. This has many benefits:
- DI doesn't waste time analyzing locals that are trivially initialized in the original source code.
- DI doesn't try to mangle canonical SIL that has been inlined from transparent functions, which may have been optimized into a form DI isn't written to understand.
While we're here, fix an issue with DCE where it would try to kill unused MarkUninitialized instructions. Although MarkUninitialized has no side effects, it still is semantically important to raw SIL, and can't be killed.
Chris did most of the work here; I just finished updating tests and fixing bugs.
Swift SVN r13247
Lower types for SILDeclRefs from the interface types of their referents, dragging the old type along for the ride so we can still offer the context to clients that haven't been weaned off of it. Make SILFunctionType's interface types and generic signature independent arguments of its Derive the context types of SILFunctionType from the interface types, instead of the other way around. Do a bunch of annoying inseparable work in the AST and IRGen to accommodate the switchover.
Swift SVN r12536
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
When we decide to emit a separate ivar initializer method (via the
Objective-C entry point -.cxx_construct), we no longer initialize the
ivars within the initializer. This only happens for derived classes,
so teach DI about uninitialized 'self' values that require a
super.init call but don't require the ivars to be initialized.
Swift SVN r12240
Builtin.addressof on an uninitialized variable. Before:
t.swift:12:26: error: variable 'self.z' captured by a closure before being initialized
p = UnsafePointer<Y>(Builtin.addressof(&z))
^
After:
t.swift:12:26: error: address of variable 'self.z' taken before it is initialized
p = UnsafePointer<Y>(Builtin.addressof(&z))
^
This resolves rdar://15699057.
Swift SVN r11482
diagnose failure to initialize with:
"return from enum initializer method without storing to 'self'"
instead of:
"variable 'self' used before being initialized"
For partially initialized super.init() calls, emit:
"super.init not called on all paths leading to use of base object 'SomeClass'"
instead of:
"use of base object 'SomeClass' before super.init call to initializes it on some paths"
... which didn't make any sense.
Swift SVN r11075
This builds on the infrastructure we have for liveness tracking, by tracking
the "super.init'd" state as another faux memory object that has a liveness.
Each escape/base class use requires super.init to have happened, and super.init
requires super.init to NOT have happened. This gives us pretty great QoI,
full fidelity to the model, and is pretty simple.
This implements:
<rdar://problem/15579247> We need to validate super.init() invariants in initializers
Swift SVN r11073
that attempted to detect whether there was an explicit init in the body.
DI takes care of this now. It also removes the logic for generating code
to default init ivars.
Swift SVN r11044
of this diagnostic still doesn't make sense (pointing the the { of the function) but that
is tracked by rdar://15581664.
t.swift:4:3: error: instance variable 'self.x' not initialized at end of initializer
init() {
^
Swift SVN r11042
t.swift:10:5: error: instance variable 'self.y' not initialized at super.init call
super.init()
^
<unknown>:0: note: variable defined here
t.swift:15:5: error: use of base object 'SomeClass' before super.init call initializes it
x = 17
^
instead of:
variable 'self.y' captured by a closure before being initialized
for each of them. <unknown> is in the crosshairs next.
Swift SVN r11036
global "partial liveness" would overwrite local "always live"ness.
Always liveness on a local level always makes a value live-out,
even if it is partially live in.
Swift SVN r11005
new mark_unitialized instructions. These defeated the alloc_box to stack promotion
pass, so everything ended up on the heap, leading to really terrible performance.
This updates things to understand mark_uninitialized, allowing us to promote them.
This fixes rdar://15607469.
Swift SVN r10985
indicate the first element that is undefined, not the first
element being accessed. In the example, passing the tuple
inout uses both elements, but the first element is initialized,
so we should complain about t2.1 being uninitialized, not t2.0
Swift SVN r10822
analyzed, and use it as common currency between the element use
collector and its clients. Element collection is about to become
more nuanced. NFC.
Swift SVN r10781
enum ctors, and add minimal updates to DI to tolerate this. Doing so
exposed a bug that would cause DI to crash handling conditional
destruction of mark_unintialized (which was never possible
before since globals aren't destructed).
Swift SVN r10778
separate passes. Start splitting some utility functions out,
and rearranging code a bit. While I'm at it, rename some bits
to make more sense now that their purpose has settled.
Swift SVN r10719
<rdar://problem/15511392> DI cannot promote loads until the initialization semantics of an entire function is known
This splits load (+destroy_addr) promotion out to a separate pass that
happens after the DI properties of an entire function are known, resolving
the problem.
The upshot is that with this fix, DI is now feature complete (and correct!) for
all known local and global variable situations (just leaving initializers to do).
The downshot is that some cleanup is required, because this is a purely mechanical
change to the previous algorithms.
Swift SVN r10702
of generating a CFG diamond with a copy of the store (in init and assign forms)
on each arm. This generalizes to operations that touch multiple tuple elements
better.
Swift SVN r10698
as is used by conditional inits. This allows some simplifications and sharing
of concepts, and makes sure that we emit at most one control variable for each
memory object being DI'd.
Swift SVN r10688
liveness of a memory object throughout the flow graph. This implements support
for conditional liveness (e.g. the testcase) of general types, but top level
tuples are not handled properly yet. This is progress to implementing
rdar://15530750.
Swift SVN r10687
and inline handleInconsistentInitOrAssign into its
caller, since it will remain simple. Also, add an
assert to make sure the handleStoreUse covers all
instructions possible in it. NFC.
Swift SVN r10685
to handle stores that are either an assign or an init, depending on the
control flow leading to them. This case needs to have a diamond inserted
in the CFG in the general case. For now, we whitelist trivial types,
since init and assign are the same for them. This fixes rdar://15530750
for trivial types.
Swift SVN r10684
anything is a proper reassignment: we only know that it could be either
InitOrAssign or Init. Classify stores as such, and then have DI classify
things into Assign when it is clearly an overwrite. This allows later
iterations to avoid reanalyzing generated instructions and allows more
precise reasoning about ambiguous initializations.
Swift SVN r10683
