Add support to the alignment support header for conjuring a character
array of a suitable size and alignment for any of a number of different
types to be stored into the character array.

The mechanisms for producing an explicitly aligned type are fairly
complex because this operation is poorly supported on all compilers.
We've spent a fairly significant amount of time experimenting with
different implementations inside of Google, and the one using explicitly
expanded templates has been the most robust.

Credit goes to Nick Lewycky for writing the first 20 versions or so of
this logic we had inside of Google. I based this on the only one to
actually survive. In case anyone is worried, yes we are both explicitly
re-contributing and re-licensing it for LLVM. =]

Once the issues with actually specifying the alignment are finished, it
turns out that most compilers don't in turn align anything the way they
are instructed. Testing of this logic against both Clang and GCC
indicate that the alignment constraints are largely ignored by both
compilers! I've come up with and used a work-around by wrapping each
alignment-hinted type directly in a struct, and using that struct to
align the character array through a union. This elaborate hackery is
terrifying, but I've included testing that caught a terrifying number of
bugs in every other technique I've tried.

All of this in order to implement a poor C++98 programmers emulation of
C++11 unrestricted unions in classes such as SmallDenseMap.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158597 91177308-0d34-0410-b5e6-96231b3b80d8
Try to reduce the size of the array used for compile-time testing by
making the bounds all '1', and chunking it a bit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158598 91177308-0d34-0410-b5e6-96231b3b80d8
Relax one assertion -- long double has strange alignments on lots of
platforms.

Also, remove one assertion on MSVC because it produces a completely
preposterous result, claiming something needs 12-byte alignment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158599 91177308-0d34-0410-b5e6-96231b3b80d8
Merge the SmallBitVector and BitVector unit tests with gtest's typed test magic and bring SmallBitVector up to date.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158600 91177308-0d34-0410-b5e6-96231b3b80d8
Update CMake build.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158601 91177308-0d34-0410-b5e6-96231b3b80d8
Mips/AsmParser/CMakeLists.txt: Fix dependency.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158602 91177308-0d34-0410-b5e6-96231b3b80d8
*no need to pollute Intel syntax with bonus mnemonics; operand size is explicitly specified

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158603 91177308-0d34-0410-b5e6-96231b3b80d8
Implement irpc. Extracted from a patch by the PaX team. I just added the test.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158604 91177308-0d34-0410-b5e6-96231b3b80d8
Move the Metadata merging methods from GVN and make them public in MDNode.

There are other passes, BBVectorize specifically, that also need some of
this functionality.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158605 91177308-0d34-0410-b5e6-96231b3b80d8
Teach BBVectorize to combine, when possible, or discard metadata when fusing instructions.

The present implementation handles only TBAA and FP metadata, discarding everything else.
For debug metadata, the current behavior is maintained (the debug metadata associated with
one of the instructions will be kept, discarding that attached to the other).

This should address PR 13040.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158606 91177308-0d34-0410-b5e6-96231b3b80d8
Cleanup trip-count finding for PPC CTR loops (and some bug fixes).

This cleans up the method used to find trip counts in order to form CTR loops on PPC.
This refactoring allows the pass to find loops which have a constant trip count but also
happen to end with a comparison to zero. This also adds explicit FIXMEs to mark two different
classes of loops that are currently ignored.

In addition, we now search through all potential induction operations instead of just the first.
Also, we check the predicate code on the conditional branch and abort the transformation if the
code is not EQ or NE, and we then make sure that the branch to be transformed matches the
condition register defined by the comparison (multiple possible comparisons will be considered).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158607 91177308-0d34-0410-b5e6-96231b3b80d8
Guard private fields that are unused in Release builds with #ifndef NDEBUG.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158608 91177308-0d34-0410-b5e6-96231b3b80d8
Disable the right instance of TheJIT, this one is only used in asserts.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158610 91177308-0d34-0410-b5e6-96231b3b80d8
Now that SROA can form alloca's for dynamic vector accesses, further improve it to be able to replace operations on these vector alloca's with insert/extract element insts

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158623 91177308-0d34-0410-b5e6-96231b3b80d8
Add some somewhat exhaustive tests of sizeof properties of this horrible
construct just for my sanity.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158637 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a SmallDenseMap container that re-uses the existing DenseMap
implementation.

This type includes an inline bucket array which is used initially. Once
it is exceeded, an array of 64 buckets is allocated on the heap. The
bucket count grows from there as needed. Some highlights of this
implementation:

- The inline buffer is very carefully aligned, and so supports types
  with alignment constraints.
- It works hard to avoid aliasing issues.
- Supports types with non-trivial constructors, destructors, copy
  constructions, etc. It works reasonably hard to minimize copies and
  unnecessary initialization. The most common initialization is to set
  keys to the empty key, and so that should be fast if at all possible.

This class has a performance / space trade-off. It tries to optimize for
relatively small maps, and so packs the inline bucket array densely into
the object. It will be marginally slower than a normal DenseMap in a few
use patterns, so it isn't appropriate everywhere.

The unit tests for DenseMap have been generalized a bit to support
running over different map implementations in addition to different
key/value types. They've then been automatically extended to cover the
new container through the magic of GoogleTest's typed tests.

All of this is still a bit rough though. I'm going to be cleaning up
some aspects of the implementation, documenting things better, and
adding tests which include non-trivial types. As soon as I'm comfortable
with the correctness, I plan to switch existing users of SmallMap over
to this class as it is already more correct w.r.t. construction and
destruction of objects iin the map.

Thanks to Benjamin Kramer for all the reviews of this and the lead-up
patches. That said, more review on this would really be appreciated. As
I've noted a few times, I'm quite surprised how hard it is to get the
semantics for a hashtable-based map container with a small buffer
optimization correct. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158638 91177308-0d34-0410-b5e6-96231b3b80d8
Add tests for *DenesMap for both key and value types' construction and
destruction and fix a bug in SmallDenseMap they caught.

This is kind of a poor-man's version of the testing that just adds the
addresses to a set on construction and removes them on destruction. We
check that double construction and double destruction don't occur.
Amusingly enough, this is enough to catch a lot of SmallDenseMap issues
because we spend a lot of time with fixed stable addresses in the inline
buffer.

The SmallDenseMap bug fix included makes grow() not double-destroy in
some cases. It also fixes a FIXME there, the code was pretty crappy. We
now don't have any wasted initialization, but we do move the entries in
inline bucket array an extra time. It's probably a better tradeoff, and
is much easier to get correct.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158639 91177308-0d34-0410-b5e6-96231b3b80d8
Disable a particular assertion on MSVC... I'm deeply disturbed by its
implementation of the class layout for the V8 type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158640 91177308-0d34-0410-b5e6-96231b3b80d8
Add a unit test for 'swap', and fix a pile of bugs in
SmallDenseMap::swap.

First, make it parse cleanly. Yay for uninstantiated methods.

Second, make the inline-buckets case work correctly. This is way
trickier than it should be due to the uninitialized values in empty and
tombstone buckets.

Finally fix a few typos that caused construction/destruction mismatches
in the counting unittest.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158641 91177308-0d34-0410-b5e6-96231b3b80d8
SmallVector: return a valid iterator for the rare case of inserting an empty range into a SmallVector.

Patch by Johannes Schaub!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158643 91177308-0d34-0410-b5e6-96231b3b80d8