Can we move to C++11 already?

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193007 91177308-0d34-0410-b5e6-96231b3b80d8
Update to reflect current GC APIs and usage. The example code is taken from the Erlang GC implementation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193008 91177308-0d34-0410-b5e6-96231b3b80d8
Remove reference to obsolete arguments.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193009 91177308-0d34-0410-b5e6-96231b3b80d8
YAMLBench.cpp: Use llvm_move instead of std::move also here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193011 91177308-0d34-0410-b5e6-96231b3b80d8
Clarify that an alignment of 0 or 1 on a mem* intrinsic means 'no alignment'.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193012 91177308-0d34-0410-b5e6-96231b3b80d8
Mark some command line flags as hidden

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193013 91177308-0d34-0410-b5e6-96231b3b80d8
Write a simple description of the 'target triple' directive. This should be expanded. PR8976.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193014 91177308-0d34-0410-b5e6-96231b3b80d8
SCEV should use NSW to get trip count for positive nonunit stride loops.

SCEV currently fails to compute loop counts for nonunit stride
loops. This comes up frequently. It prevents loop optimization and
forces vectorization to insert extra loop checks.

For example:
void foo(int n, int *x) {
 for (int i = 0; i < n; i += 3) {
   x[i] = i;
   x[i+1] = i+1;
   x[i+2] = i+2;
 }
}

We need to properly handle the case in which limit > INT_MAX-stride. In
the above case: n > INT_MAX-3. In this case the loop counter will step
beyond the limit and overflow at the same time. However, knowing that
signed integer overlow in undefined, we can assume the loop test
behavior is arbitrary after overflow. This obeys both C undefined
behavior rules, and the more strict LLVM poison value rules.

I'm finally fixing this in response to Hal Finkel's persistence.
The most probable reason that we never optimized this before is that
we were being careful to handle case where the developer expected a
side-effect free infinite loop relying on overflow:

for (int i = 0; i < n; i += s) {
  ++j;
}
return j;

If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might
expect an infinite loop. However there are plenty of ways to achieve
this effect without relying on undefined behavior of signed overflow.

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