[x86] Start fixing a really subtle and terrible form of miscompile in
these DAG combines.

The DAG auto-CSE thing is truly terrible. Due to it, when RAUW-ing
a node with its operand, you can cause its uses to CSE to itself, which
then causes their uses to become your uses which causes them to be
picked up by the RAUW. For nodes that are determined to be "no-ops",
this is "fine". But if the RAUW is one of several steps to enact
a transformation, this causes the DAG to really silently eat an discard
nodes that you would never expect. It took days for me to actually
pinpoint a test case triggering this and a really frustrating amount of
time to even comprehend the bug because I never even thought about the
ability of RAUW to iteratively consume nodes due to CSE-ing them into
itself.

To fix this, we have to build up a brand-new chain of operations any
time we are combining across (potentially) intervening nodes. But once
the logic is added to do this, another issue surfaces: CombineTo eagerly
deletes the one node combined, *but no others*. This is... really
frustrating. If deleting it makes its operands become dead, those
operand nodes often won't go onto the worklist in the
order you would want -- they're already on it and not near the top. That
means things higher on the worklist will get combined prior to these
dead nodes being GCed out of the worklist, and if the chain is long, the
immediate users won't be enough to re-detect where the root of the chain
is that became single-use again after deleting the dead nodes. The
better way to do this is to never immediately delete nodes, and instead
to just enqueue them so we can recursively delete them. The
combined-from node is typically not on the worklist anyways by virtue of
having been popped off.... But that in turn breaks other tests that
*require* CombineTo to delete unused nodes. :: sigh ::

Fortunately, there is a better way. This whole routine should have been
returning the replacement rather than using CombineTo which is quite
hacky. Switch to that, and all the pieces fall together.

I suspect the same kind of miscompile is possible in the half-shuffle
folding code, and potentially the recursive folding code. I'll be
switching those over to a pattern more like this one for safety's sake
even though I don't immediately have any test cases for them. Note that
the only way I got a test case for this instance was with *heavily* DAG
combined 256-bit shuffle sequences generated by my fuzzer. ;]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216319 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "ARM: mark missing functions from RTABI"

This reverts commit r215863.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216324 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "ARM: improve RTABI 4.2 conformance on Linux"

This reverts commit r215862 due to nightly failures.  Will work on getting a
reduced test case, but I wanted to get our bots green in the meantime.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216325 91177308-0d34-0410-b5e6-96231b3b80d8
cmake: disable -Wnon-virtual-dtor when it gives false positives

clang has only been smart enough not to trigger -Wnon-virtual-dtor
warnings on final classes since r208449 (in clang 3.5). Building
with older versions is extremely noisy, so disable the warning
on those compilers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216327 91177308-0d34-0410-b5e6-96231b3b80d8
cmake: actually test -Wcomment

This test was testing nothing, as only -Werror was ever
being added to the compiler flags.

You can see the final nitty-gritty compiler invocation in
CMakeFiles/CMakeOutput.log (for successful tests) and
CMakeFiles/CMakeError.log (for failed tests).

Before:
Building C object CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o
/usr/bin/clang   -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default  -DC_WCOMMENT_ALLOWS_LINE_WRAP  -Werror   -o CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o   -c /home/nobled/code/llvm-b9/CMakeFiles/CMakeTmp/src.c

After:
Building C object CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o
/usr/bin/clang   -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default  -DC_WCOMMENT_ALLOWS_LINE_WRAP  -Werror -Wcomment   -o CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o   -c /home/nobled/code/llvm-b9/CMakeFiles/CMakeTmp/src.c

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216328 91177308-0d34-0410-b5e6-96231b3b80d8
Support/Unix: use ScopedLock wherever possible

Only one function remains a bit too complicated
for a simple mutex guard. No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216335 91177308-0d34-0410-b5e6-96231b3b80d8
Support: make LLVM Mutexes STL-compatible

Use lock/unlock() convention instead of acquire/release().

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

Based on the STL class of the same name, it guards a mutex
while also allowing it to be unlocked conditionally before
destruction.

This eliminates the last naked usages of mutexes in LLVM and
clang.

It also uncovered and fixed a bug in callExternalFunction()
when compiled without USE_LIBFFI, where the mutex would never
be unlocked if the end of the function was reached.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216338 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Add support for dcbtst and icbt (prefetch)

Adds code generation support for dcbtst (data cache prefetch for write) and
icbt (instruction cache prefetch for read - Book E cores only).

We still end up with a 'cannot select' error for the non-supported prefetch
intrinsic forms. This will be fixed in a later commit.

Fixes PR20692.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216339 91177308-0d34-0410-b5e6-96231b3b80d8
InstCombine: Properly optimize or'ing bittests together

CFE, with -03, would turn:
bool f(unsigned x) {
  bool a = x & 1;
  bool b = x & 2;
  return a | b;
}

into:
  %1 = lshr i32 %x, 1
  %2 = or i32 %1, %x
  %3 = and i32 %2, 1
  %4 = icmp ne i32 %3, 0

This sort of thing exposes a nasty pathology in GCC, ICC and LLVM.

Instead, we would rather want:
  %1 = and i32 %x, 3
  %2 = icmp ne i32 %1, 0

Things get a bit more interesting in the following case:
  %1 = lshr i32 %x, %y
  %2 = or i32 %1, %x
  %3 = and i32 %2, 1
  %4 = icmp ne i32 %3, 0

Replacing it with the following sequence is better:
  %1 = shl nuw i32 1, %y
  %2 = or i32 %1, 1
  %3 = and i32 %2, %x
  %4 = icmp ne i32 %3, 0

This sequence is preferable because %1 doesn't involve %x and could
potentially be hoisted out of loops if it is invariant; only perform
this transform in the non-constant case if we know we won't increase
register pressure.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216344 91177308-0d34-0410-b5e6-96231b3b80d8
X86 intrinsics table - simplifies intrinsics lowering.
The tables are initialized when X86TargetLowering object is created.


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