Don't use nopl in cpus that don't support it.

Patch by Mikulas Patocka. I added the test. I checked that for cpu names that
gas knows about, it also doesn't generate nopl.

The modified cpus:
i686 - there are i686-class CPUs that don't have nopl: Via c3, Transmeta
        Crusoe, Microsoft VirtualBox - see
        https://bbs.archlinux.org/viewtopic.php?pid=775414
k6, k6-2, k6-3, winchip-c6, winchip2 - these are 586-class CPUs
via c3 c3-2 - see https://bugs.archlinux.org/task/19733 as a proof that
        Via c3 and c3-Nehemiah don't have nopl

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195679 91177308-0d34-0410-b5e6-96231b3b80d8
Use -triple to fix the test on non-ELF hosts.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195682 91177308-0d34-0410-b5e6-96231b3b80d8
Do the string comparison in the constructor instead of once per nop.

Thanks to Roman Divacky for the suggestion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195684 91177308-0d34-0410-b5e6-96231b3b80d8
Add the test case that I missed when committing r195528. Doh!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195691 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Pubtypes: Coelesce pubtype registration with accelerator type registration.

It might be possible to eventually use one data structure, but I haven't
looked at the exact criteria used for accelerator tables and pubtypes to
see if there's good reason for the differences between the two or not.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195696 91177308-0d34-0410-b5e6-96231b3b80d8
Add an intrinsic for the SSE2 PAUSE instruction.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195697 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Avoid emitting pubtype entries for type DIEs that just indirect to a type unit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195698 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Clean up a bunch of comments, modernize the doxygen, nuke some
whitespace, and a couple of argument name fixes before I start hacking
on this code. No functionality changed here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195699 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Remove CompileUnit::constructTypeDIEImpl now that it's just a simple wrapper again.

r195698 moved the type unit checking up into getOrCreateTypeDIE so
remove the redundant check and fold the functions back together again.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195700 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Rename the 'Mod' member to the more idiomatic 'M'. No functionality
changed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195701 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Sink a trailing comment to be a doxygen comment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195702 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a self-memcpy which only breaks under Valgrind's memcpy
implementation. Silliness, but it'll be a trivial performance
optimization. This should clear up a failure on the vg_leak bot.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195704 91177308-0d34-0410-b5e6-96231b3b80d8
Lift self-copy protection up to the header file and add self-move
protection to the same layer.

This is in line with Howard's advice on how best to handle self-move
assignment as he explained on SO[1]. It also ensures that implementing
swap with move assignment continues to work in the case of self-swap.

[1]: http://stackoverflow.com/questions/9322174/move-assignment-operator-and-if-this-rhs

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195705 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Update test case due to dumper improvements in r195698

The dumper was only dumping one pubtypes set and it was /always/ dumping
one pubtypes set even when there were zero sets. Now that the dumper
correctly dumps zero, one, or many sets, we can update this test case to
test for the absolute absence of a set rather than a bogus/accidental
zero-valued set.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195706 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Reformat this file with clang-format. Mostly fixes inconsistent
spacing around the '*' in pointer types. Will let me use clang-format on
subsequent changes without introducing any noise. No functionality
changed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195708 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Make the (really awesome) file comment here available as part of
the Doxygen.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195711 91177308-0d34-0410-b5e6-96231b3b80d8
StackMap: Implement support for DirectMemRefOp.

A Direct stack map location records the address of frame index. This
address is itself the value that the runtime requested. This differs
from IndirectMemRefOp locations, which refer to a stack locations from
which the requested values must be loaded. Direct locations can
directly communicate the address if an alloca, while IndirectMemRefOp
handle register spills.

For example:

entry:
  %a = alloca i64...
  llvm.experimental.stackmap(i32 <ID>, i32 <shadowBytes>, i64* %a)

Since both the alloca and stackmap intrinsic are in the entry block,
and the intrinsic takes the address of the alloca, the runtime can
assume that LLVM will not substitute alloca with any intervening
value. This must be verified by the runtime by checking that the stack
map's location is a Direct location type. The runtime can then
determine the alloca's relative location on the stack immediately after
compilation, or at any time thereafter. This differs from Register and
Indirect locations, because the runtime can only read the values in
those locations when execution reaches the instruction address of the
stack map.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195712 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64]Implement 128 bit register copy with NEON.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195713 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Re-format this code with clang-format before making substantial
changes to it. No functionality changed.

You may wonder why on earth touching this code is involved in the pass
manager work as indicated by my lovely '[PM]' tag? Let me tell you
a story.

<redacted>

Yea, it's too long of a story. Let us say that there are yaks, many of
them. I am busy shaving them as fast as I can.

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