Initial file skeleton
More work toward SROA of awesome
another checkpoint
Completely re-write splitting, and it compiles even! Working on testing
and debugging now.
Teach the builder to visit mem intrinsics and add the constant sized ones as uses.
Start expanding the basic testing, and add some more info to the print out.
Make debugging easier by ensuring that dump is always available.
Teach the splitting to handle the trailing ends of splittable regions, and make the test case even more interesting.
Make the test more interesting and pave the way for subsequent testing.

This adds a sequence of overlapping unsplittable stores that will be
detected and cause a single split of the splittable overlaps.
Add a typedef for the split set iterator, thanks to a comment on IRC.
Big checkpoint. This adds a much more thorough test of the splitting
infrastructure, now with multiple bridged overlapping regions,
challenging splits, etc.

With it are numerous fixes to the split algorithm itself. It now
correctly splits all of these patterns, but the bridging splits are
sub-optimal as it fails to fully partition the bridges, instead creating
overlapped bridges. I have some code if-ed out which implements
partitioned bridge building, but only for the tail of the algorithm.
I need to refactor it to work when building fully generic bridges.
Major refactoring and a lot of crazy code to sink users through the
split set eagerly.

The goal here is that the bottom of the split set is both the shortest
split partition, and also contains the union of users for all other
split partitions in the set. This amortizes the linear walk over the set
to build up user lists for each partition.

The trade off is a significant amount of complexity in merging new
partitions into the split set.

Other significant change here came out of the refactoring: we now have
a single shared code path for building up the set of partitions either
within an overlapping region or between two non-overlapping regions.
This results in somewhat less nice IR for the overlapping regions, but
allows the set logic above to work better in addition to making the
bridge partitions perfectly split.
Reduce indentation.
Remove some dead code and reshuffle
Add a fixme about the big remaining scaling issue.
Add another fixme about a potential optimization.
Add in an initial sketch of promotion and rewriting of users.

The current implementation is completely dependent upon PromoteMemToReg
which has a really terrible interface, but so far this adds support for
the following use cases of actual SROA:
- Boring scalar allocas are now immediately queued for promotion.
- Impossible to SROA allocas are properly skipped, and skipped early.
- Allocas which are partitioned into a set of loads and stores should be
  promoted to a set of scalar allocas. However, we don't yet recurse.

This patch is mostly about building up the infrastructure for doing
this. It refactors the pass so that we can easily split up functions for
walking through the partition, it adds the DomTree requirement and
threads it through, as well as threading the context through for type
creation. It adds an alloca rewriter InstVisitor that actually performs
the rewriting.

It also adds a lot of debugging aids for rewriting. The printing is
split out so that we can easily dump nice inforamtion in -debug mode for
each rewrite step taken. Also, I've taken some care to try to stash as
much information about the rewriting occuring in the instruction names
synthesized to hopefully make subsequent debugging easier.

Also added the most trivial of test of the mem2reg functionality to
basictest.ll for my sanity.
A bit more debugging code, and thread logic to track whether the result
of a split and rewritten alloca is promotable. Use that to actually
promote the split allocas when we can.

Again, this is mostly plumbing. The hard part will be fleshing out the
rewriter.
Switch fully over the 'Partition' nomenclature rather than 'Use'
nomenclature.

The latter is too damn confusing in the presence of LLVM's 'Use'. I've
retained a 'Users' list, as that is at least a better fitting name.
Add some comments about the crazy split algorithm, mostly the magical
split set. No idea if these really make sense out of the context of the
code, but at least stashed here in the datastructure they don't
interrupt the flow.