takes a SILType instead of a MemLocation, BreadthFirstList will be used to expand
memory values in RLE as well.
Existing test cases make sure refactoring did not break anything.
Swift SVN r32739
This reverts commit r32338 because it appears to have broken Havlak
under the leaks runner, as well as Dictionary and Set on the iOS
simulator.
Swift SVN r32341
This means that we will not explode things like:
struct A { var b: B }
struct B { var c: C }
struct C { var leaf: LeafType }
This does not add anything since all of the types are layout
compatible.
In terms of effect on dylib size, there is a small reduction (i.e. < 1%) over
all dylibs. The only really significant change is to Foundation which shrinks by
3%.
rdar://21114206
Swift SVN r29780
We know if the analysis fails by calling the canForward method instead of using
the failable static initializers. I am worried about unnecessary copies resulting
from the failable initializers.
Swift SVN r29466
Moved the lightweight access path helper into a ProjectionIndex utility.
Added support to it and the kitchen-sink Projection utility.
Add a ProjectionIndex utility that supports IndexAddr and does only what it needs to do.
While I'm at it, add IndexAddr support to Projection and
ProjectionPath so that other passes can make use of it.
Unfortunately, LoadStore optimization is still not strong enough to
benefit, so I don't have a test case yet.
Note that we have to be very careful now not to assume that when one
projection path is a subsequence of another it must address an
containing region of memory. The implicit index_addr #0 is not part of
the projection path!
Swift SVN r29167
Re-enable function argument explosion during function signature
optimization in the case where there are between one and three live leaf
elements of the projection tree for the argument.
Three is an arbitrary limit, which we can consider tuning later, or
replacing with a better heuristic.
There are many limitations in what we can do at the SIL level to make a
good choice for this transformation, and this is just an attempt to keep
the transformation firing in some limited use cases where it is
relatively likely to be worthwhile rather than disabling it entirely.
I attempted to re-enable most of the test case that was disabled in
r29047.
This appears to eliminate or at least greatly reduce the regression
measured in the CaptureProp benchmark from the change in r29047.
Swift SVN r29062
And also adapt a whole set of SIL passes so that they can deal with (the not deleted) debug_value instructions.
This was required to prevent perforamnce and code size regressions.
Now the generated code is (almost) the same as before.
The effect of this change is that we keep debug_value/debug_value_addr also in optimized code (more or less).
Fixes rdar://problem/18709125.
Swift SVN r28872
Previously I was using a large SmallVector to create Nodes for the
ProjectionTree. This created an issue when the SmallVector would convert
from small to large representation in the middle of a method on an
object that is stored in the SmallVector. Thus the 'this' pointer will
be invalidated and all sorts of fun times will occur.
I switched now to using a BumpPtrAllocator which is passed into the tree
and used in FunctionSignatureOptimization for all projection trees.
<rdar://problem/19534462>
Swift SVN r24706
A "Projection Tree" takes in a type and constructs a tree where each non-leaf
node represents an aggregate that can be split up and all leaf nodes represent a
subtype of the original type that we can not split.
It additionally provides the capability to propagate usage information
and liveness information through the tree, making it trivial to perform
SROA + partial dead use elimination. I am using this in function
signature opts for that purpose.
Swift SVN r23586
I want to cleanup some code paths in SILCombine and LoadStoreOpts to use
generic create{Addr,Value}Projection methods which create the
appropriate projection instruction for a Projection method. Also this
will allow me to start to hide more of the internal state of Projection.
Swift SVN r23366
This changes the Projection API so that you pass in an instruction and get back
an optional depending on what theinstruction was. This is much cleaner than
always needing to do a switch.
This commit also cleans up the naming in Projection so that we always use the
term "value projection" for struct_extract, tuple_extract, and
unchecked_enum_data instead of the term "extract". This lines up better with the
name we use for the *_addr instructions, "address projection" and avoids
ambiguity since unchecked_enum_data does not have the word "extract" in it.
Additionally by adding in the failable initializers, my centralization of the
initialization logic enables me to ensure that isAddrProjection and
isValueProjection stay in sync with the various constructors via asserts. This
should prevent future bugs if we add additional notions of "projection".
Swift SVN r23356
This is apart of some cleanups of the Projection class.
I also improved the comment at the top of projection to make its usage
clearer.
Swift SVN r23355
This will help the ARC optimizer given future function sig optimization work and
is in general good since this has been a hole in our load store forwarding for a
while.
rdar://18831605
Swift SVN r23102
We ignore casts when generating projection paths for alias analysis. When
comparing two paths, we say no alias when accessing different fields of
the same Decl Context.
Swift SVN r20353
A first element field of a nominal type is either the first element of a
struct or the first payload of an enum. We currently allow the stdlib to
rappel into struct heirarchies using reinterpretCast. This patch teaches
the optimizer how to rewrite such unchecked_addr_cast into
unchecked_enum_data_addr and struct_element_addr instructions. Then
Mem2Reg and Load Store Forwarding will remove the allocation generated
by such uses of reinterpret cast.
<rdar://problem/16703656>
Swift SVN r18977
Instead for vardecls, we use the index of the field in the structdecl itself as
a stable ordering of vardecls.
I validated that the indeterminism was gone by running the failing test 1000
times in a row. Doug and I were hitting the indeterminism with well less than
100 iterations before, so I feel the number of iterations is sufficient.
Swift SVN r13859
This class allows you to deal with tuple and nominal projections in a way that
is agnostic of either of them.
Expect some incoming utilities based off of this for dealing with what I call
'aggregate type trees'.
Swift SVN r13735
