This is essentially a ground up re-think of the SROA pass in LLVM. It
was initially inspired by a few problems with the existing pass:
- It is subject to the bane of my existence in optimizations: arbitrary
  thresholds.
- It is overly conservative about which constructs can be split and
  promoted.
- The vector value replacement aspect is separated from the splitting
  logic, missing many opportunities where splitting and vector value
  formation can work together.
- The splitting is entirely based around the underlying type of the
  alloca, despite this type often having little to do with the reality
  of how that memory is used. This is especially prevelant with unions
  and base classes where we tail-pack derived members.
- When splitting fails (often due to the thresholds), the vector value
  replacement (again because it is separate) can kick in for
  preposterous cases where we simply should have split the value. This
  results in forming i1024 and i2048 integer "bit vectors" that
  tremendously slow down subsequnet IR optimizations (due to large
  APInts) and impede the backend's lowering.

The new design takes an approach that fundamentally is not susceptible
to many of these problems. It is the result of a discusison between
myself and Duncan Sands over IRC about how to premptively avoid these
types of problems and how to do SROA in a more principled way. Since
then, it has evolved and grown, but this remains an important aspect: it
fixes real world problems with the SROA process today.

First, the transform of SROA actually has little to do with replacement.
It has more to do with splitting. The goal is to take an aggregate
alloca and form a composition of scalar allocas which can replace it and
will be most suitable to the eventual replacement by scalar SSA values.
The actual replacement is performed by mem2reg (and in the future
SSAUpdater).

The splitting is divided into four phases. The first phase is an
analysis of the uses of the alloca. This phase recursively walks uses,
building up a dense datastructure representing the ranges of the
alloca's memory actually used and checking for uses which inhibit any
aspects of the transform such as the escape of a pointer.

Once we have a mapping of the ranges of the alloca used by individual
operations, we compute a partitioning of the used ranges. Some uses are
inherently splittable (such as memcpy and memset), while scalar uses are
not splittable. The goal is to build a partitioning that has the minimum
number of splits while placing each unsplittable use in its own
partition. Overlapping unsplittable uses belong to the same partition.
This is the target split of the aggregate alloca, and it maximizes the
number of scalar accesses which become accesses to their own alloca and
candidates for promotion.

Third, we re-walk the uses of the alloca and assign each specific memory
access to all the partitions touched so that we have dense use-lists for
each partition.

Finally, we build a new, smaller alloca for each partition and rewrite
each use of that partition to use the new alloca. During this phase the
pass will also work very hard to transform uses of an alloca into a form
suitable for promotion, including forming vector operations, speculating
loads throguh PHI nodes and selects, etc.

After splitting is complete, each newly refined alloca that is
a candidate for promotion to a scalar SSA value is run through mem2reg.

There are lots of reasonably detailed comments in the source code about
the design and algorithms, and I'm going to be trying to improve them in
subsequent commits to ensure this is well documented, as the new pass is
in many ways more complex than the old one.

Some of this is still a WIP, but the current state is reasonbly stable.
It has passed bootstrap, the nightly test suite, and Duncan has run it
successfully through the ACATS and DragonEgg test suites. That said, it
remains behind a default-off flag until the last few pieces are in
place, and full testing can be done.

Specific areas I'm looking at next:
- Improved comments and some code cleanup from reviews.
- SSAUpdater and enabling this pass inside the CGSCC pass manager.
- Some datastructure tuning and compile-time measurements.
- More aggressive FCA splitting and vector formation.

Many thanks to Duncan Sands for the thorough final review, as well as
Benjamin Kramer for lots of review during the process of writing this
pass, and Daniel Berlin for reviewing the data structures and algorithms
and general theory of the pass. Also, several other people on IRC, over
lunch tables, etc for lots of feedback and advice.

llvm-svn: 163883

llvm-svn: 163882

llvm-svn: 163881

Allow the second opcode info table to be 8, 16, or 32-bits as needed to represent additional fragments. This recovers some space on ATT X86 syntax and PowerPC which only need 40-bits instead of 48-bits. This also increases ARM to 64-bits to fully encode all of its operands.

llvm-svn: 163880

llvm-svn: 163879

Reduce size of register name index tables by using uint16_t for all in tree targets. If more than 16-bits are needed for any out of tree targets, code will detect and use uint32_t instead.

llvm-svn: 163878

This is mostly documentation for the new machine model. It is designed
to be flexible, easy to incrementally refine for a subtarget, and
provide all the information that MachineScheduler will need.

If all goes well, I will follow up with an example of the new model in
use for ARM.

llvm-svn: 163877

llvm-svn: 163876

llvm-svn: 163875

llvm-svn: 163874

without a cast. Fixes <rdar://problem/11830912>.

llvm-svn: 163873

[asan] add asan option log_path=PATH to let users redirect asan reports to a file PATH.PID instead of stderr

llvm-svn: 163872

type checking for non-static data member initializers in a dependent
class, because our ASTs lose too much information to when
type-checking an initializer. Fixes <rdar://problem/11974632>,
although the result is still rather unsatisfactory.

llvm-svn: 163871

llvm-svn: 163870

1. Add MoveR3216
2. Correct spelling for Move32R16

Patch by Reed Kotler.

llvm-svn: 163869

When attaching on ARM hosted debuggers we were incorrectly setting the triple to "arm-apple-ios". This was happening because in the post attach code, we would lookup the process info through the platform, and if successful, we would get the architecture of the process. This code uses sysctl() calls, but we can only get the CPU type, not the subtype, so we would get ARM for CPU type and nothing for the cpu subtype, so this would map to "arm-apple-ios". I fixed the code to get the cpu subtype from "hw.cpusubtype" which is what we really want for ARM, and not the architecture is already correct. "add-dsym" then works like a charm. I also improved the command output when the architecture changes to show the entire triple instead of just the arch name.

llvm-svn: 163868

llvm-svn: 163867

both a virtual and a non-virtual offset. PR13832.

llvm-svn: 163866

llvm-svn: 163865

<rdar://problem/12293231>

llvm-svn: 163864

llvm-svn: 163863

Dimitry Andric:  many visibility fixes.  Howard:  Much appreciated.  Can you send me a patch to CREDITS.TXT?

llvm-svn: 163862

llvm-svn: 163861

The patch converts the "How to add a builder" document over to reStructuredText..

llvm-svn: 163860

Specifically disallow primary-expressions of the form LT_... on the basis of this decition: http://sourcerytools.com/pipermail/cxx-abi-dev/2011-August/002422.html .  Failure to disallow this was causing infinite recursion in the demangler when these symbols show up due to mangling bugs.  This patch causes the demangler to return an invalid mangled name result rather than crash in infinite recursion.

llvm-svn: 163859

ivar and property references as member accesses and produce the actual
type of the declaration. Fixes <rdar://problem/12031582>.

llvm-svn: 163858

them in one place rather than having them replicated
across all the potential function wrappers.

<rdar://problem/12293880>

llvm-svn: 163857

umulo legalization.

Fixes PR13839

llvm-svn: 163856

closer to where they're needed.

llvm-svn: 163855

For gas compatibility.

rdar://12219394

llvm-svn: 163854

.set a, b - c + CONSTANT
d = b - c + CONSTANT

Both 'a' and 'd' should be marked as absolute symbols (N_ABS).

rdar://12219394

llvm-svn: 163853

llvm-svn: 163852

llvm-svn: 163851

llvm-svn: 163850

llvm-svn: 163849

type of an instantiation.

llvm-svn: 163848

llvm-svn: 163846

TypeSourceInfo, we may have lost some adjustments made to the type of
that function due to declaration merging. Adjust the resulting type
correspondingly. Fixes PR12948 / <rdar://problem/11552434>.

llvm-svn: 163845

loads and stores.

llvm-svn: 163844

mapSectionAddress() wasn't consistent.

llvm-svn: 163843