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
tag things known from SILGen to be initializers (e.g., copyaddrs with
the bit set) and when we analyze the DI properties for an assign, we
can move it to this classification. This allows stuff that wants to
reason about the difference (e.g. the conditional destroy logic) to
do so precisely.
Swift SVN r10658
logic for destroy_addrs of memory that is only live on some
paths. This finally wraps up rdar://15209088.
The final missing DI feature for local/global variables is the
conditional "assign" vs "init" case now.
Swift SVN r10654
each element has a known yes/no liveness, as a generalization of the
"none are alive" logic. Now the only piece missing is the
flow sensitive liveness case.
It is pretty nice that DI is able to transform the testcase into this
simple logic:
sil @release_some_constructed : $@thin () -> () {
bb0:
%0 = tuple ()
%1 = function_ref @getSomeClass : $@thin () -> @owned SomeClass // user: %2
%2 = apply %1() : $@thin () -> @owned SomeClass // user: %3
strong_release %2 : $SomeClass // id: %3
%4 = tuple () // user: %5
return %4 : $() // id: %5
}
Swift SVN r10629
into two methods: one that determines the liveness of a set of
elements at a point in the CFG, and one the merges the result
across the elements used by a particular access. The
getLivenessAtUse is useful for traditional DI properties, but
the vector-returning one is important for analyzing the liveness
at a release. Still no functionality change.
Swift SVN r10625
that wraps llvm::SmallVector of bit pairs - centralizing the logic
for working on it, and abstracting the bit pair encoding. Also
add a comment describing what this is doing in lattice theoretic
terms.
Swift SVN r10624
This fixes up various testcases. Note that 3 debug info tests are asserting
in IRGen for a common but unknown-to-me reason, I've XFAILed them for now.
Swift SVN r10613
Doing this exposed that the dataflow analysis in DI was pretty fundamentaly broken:
it was trying to compute blocks where the (tuple elements of the) memory were either
initialized, uninitialized, or partially initialized (initialized only on some paths)
but it conflated partial with its unknown state, causing it to get the wrong results
a lot of the time. Rewrite things so that it is correct.
Swift SVN r10594
loading from our current allocation, we'd sometimes add loads
corresponding to the "assign" to the use list for this memory
object.
No testcase as this will be tested by Joe's forthcoming patch
to produce more copyaddrs from silgen.
Swift SVN r10559
Fix DI to not delete non-trivial memory allocations that are still
used by destroy_addr or strong_release, since just dropping those operations
will cause a memory leak.
This is simple, but prevents DI from removing most allocations. To
avoid having to update all the testcases :), teach it also to promote
non-address-only destroy_addrs into a load+release sequence when the
load's value is available, as part of normal load promotion.
Swift SVN r10542
so they don't need code motion on releases. This fixes Jordan's testcase from
rdar://15209088, though non-trivial types still don't work.
Swift SVN r10539
instead of working a tuple-element at a time. This requires it
to use bitvectors to compute each tuple element's liveness separately.
A big part of this is introducing the new MemoryUse type, which wraps
up the tuple elements accessed by a user of the memory object in addition
to its kind, and extending the NonLoadUses set to keep an index into the
Uses map, and a lot of other things.
This wraps up:
<rdar://problem/15228619> Eliminate the notion of Element from DefiniteInitialization
Swift SVN r10520
since they are handled in a completely different way from other uses
and already had to be std::partitioned to the end anyway. They will
only become more different over time.
Swift SVN r10500
We were incorrectly treating init_existential as equivalent to a struct
access, where for DI purposes, it is much more like an enum access: a store
to the result of a (not further indexed) init_existential pointer should be
treated as a full store, not a partial store.
Swift SVN r9933
functions. Before it would only delete them once they got inlined,
which is a waste of compile time and serves no purpose.
This exposed a bug in mandatory inlining, which is now fixed. It
strinks the stdlib by 4500 lines, almost 10%.
Swift SVN r9906
