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
