llvm-svn: 204667

v2:
  - Use a hexadecimal constant.

v3:
  - Use a hexadecimal constant in floating-point notation.

llvm-svn: 204666

llvm-svn: 204665

Having these popping up every time you use -debug is really
irritating.

llvm-svn: 204664

llvm-svn: 204663

Check the register class of each operand individually
to avoid an extra copy to a vgpr.

llvm-svn: 204662

No longer asserts, but now you get moves loading legal immediates
into the split 32-bit operations.

llvm-svn: 204661

Try to match scalar and first like the other instructions.
Expand 64-bit ands to a pair of 32-bit ands since that is not
available on the VALU.

llvm-svn: 204660

never returns, which is true by design. 

Initially assumed that the reason is llvm_unreachable being dependent on NDEBUG.

However, even if llvm_unreachable is replaced by __assume(false), VC still warns in
Release modes but not in Debug modes...

The real reason turned out to be optimization flags.
With /Od in Debug modes the warning is not issued whereas with /O1 it is.

I could not find any documentation to this effect, but it is reproducable:

Try compiling http://msdn.microsoft.com/en-us/library/khwfyc5d(v=vs.90).aspx
with /O1 and then with /Od.

llvm-svn: 204659

llvm-svn: 204658

Capability attributes can now be declared on a typedef declaration as well as a structure declaration. This allows for C code to use Boolean expressions on a capability as part of another attribute. Eg) __attribute__((requires_capability(!SomeCapability)))

llvm-svn: 204657

Make vector clock operations O(1) for several important classes of use cases.
See comments for details.
Below are stats from a large server app, 77% of all clock operations are handled as O(1).

Clock acquire                     :         25983645
  empty clock                     :          6288080
  fast from release-store         :         14917504
  contains my tid                 :          4515743
  repeated (fast)                 :          2141428
  full (slow)                     :          2636633
  acquired something              :          1426863
Clock release                     :          2544216
  resize                          :             6241
  fast1                           :           197693
  fast2                           :          1016293
  fast3                           :             2007
  full (slow)                     :          1797488
  was acquired                    :           709227
  clear tail                      :                1
  last overflow                   :                0
Clock release store               :          3446946
  resize                          :           200516
  fast                            :           469265
  slow                            :          2977681
  clear tail                      :                0
Clock acquire-release             :           820028

llvm-svn: 204656

llvm-svn: 204655

llvm-svn: 204654

Also mark #2104 as complete. Leave the implementation in libc++ as noexcept, since 
implementations are allowed to add noexcept to non-virtual calls. If we throw from
unique_lock& operator=(unique_lock&& u), then that means the preconditions were violated,
and calling terminate() (as a result of throwing from a noexcept function) is as
good example of undefined behavior as any other.

llvm-svn: 204653

FreeBSD recently updated to Clang 3.4 and the TestFormatters test case
started failing as it omits the C1 complete object constructor when not
needed.

llvm.org/pr19011

llvm-svn: 204652

llvm-svn: 204651

Adding some very nascent information about the clang tablegen backends, with a promise to add more information later.

llvm-svn: 204635

As a first step towards real little-endian code generation, this patch
changes the PowerPC MC layer to actually generate little-endian object
files.  This involves passing the little-endian flag through the various
layers, including down to createELFObjectWriter so we actually get basic
little-endian ELF objects, emitting instructions in little-endian order,
and handling fixups and relocations as appropriate for little-endian.

The bulk of the patch is to update most test cases in test/MC/PowerPC
to verify both big- and little-endian encodings.  (The only test cases
*not* updated are those that create actual big-endian ABI code, like
the TLS tests.)

Note that while the object files are now little-endian, the generated
code itself is not yet updated, in particular, it still does not adhere
to the ELFv2 ABI.

llvm-svn: 204634

This was failing on an internal branch where the order was different for
some reason. <rdar://problem/16407581>

llvm-svn: 204633

llvm-svn: 204632

Those patterns are used when the load cannot be folded into the related broadcast
during the select phase.
This happens when the load gets additional uses that were not anticipated during
the previous lowering phases (constant vector to constant load, then constant
load reused) or when selection DAG is not able to prove that folding the load
will not create a cycle in the DAG.

<rdar://problem/16074331>

llvm-svn: 204631

llvm-svn: 204630

Previously we would print an error message on machines where the only VS
version we find is 2013, even though we successfully install the integration
files for it.

Also, we shouldn't have two END labels.

llvm-svn: 204629

It is to avoid build error when gcc defines i386.

llvm-svn: 204628

Additional clarification from Uli for the background on _CALL_ELF:
"Historically GCC has provided various _CALL_... predefines depending on the
ABI currently being compiled for. (_CALL_SYSV,_CALL_AIXDESC, _CALL_DARWIN )
When we needed a new define for the current ABI, we decided on using _CALL_ELF
since the official name of the ABI is the OpenPower ElfV2 ABI, with the
current Linux ABI retro-actively being renamed the ELFv1 ABI
and so we decided on using _CALL_ELF to identify the Linux (+BSD etc.) ELF ABI,
with _CALL_ELF=1 for the v1 ABI and _CALL_ELF=2 for the v2 ABI.
(Note that this matches the gcc compiler switch -mabi=elfv1 vs. -mabi=elfv2)."

In code, a (_CALL_ELF==2) check will indicate when the ELFv2 ABI is
to be used.   This is the desired default for the PPC64 LE target.

llvm-svn: 204627

Update the parameters passed to the assembler and linker for
the PPC64LE target.  Specifically:
(assembler) adds/uses  -mppc64 -mlittle-endian
(linker) adds/uses  elf64lppc

Testcase included.

llvm-svn: 204626

Make sure such IR gets properly lowered to PTX.

llvm-svn: 204624

This can be observed with the old testcase of CodeGen/X86/pr12312.ll:

47c47
<       vorps   %ymm0, %ymm1, %ymm0
---
>       vorps   %ymm1, %ymm0, %ymm0
97c97
<       vorps   %ymm1, %ymm0, %ymm0
---
>       vorps   %ymm0, %ymm1, %ymm0

The vector VecIns is populated with all the values from VecInMap. This is done
while iterating VecInMap.  VecInMap uses a hash of pointer values so the
resulting order can vary depending on the memory layout.

The fix is to populate the vector VecIns earlier as VecInMap is populated.
This is done in DAG traversal order.

Fixes <rdar://problem/16398806>

llvm-svn: 204623

Modified patch from Piotr Rak that makes GetSharedModuleList() more thread safe and also fixed a missed member initialization on the copy contractor and also makes the assignment operator safer.

llvm-svn: 204622

Summary:
Patch by David Chisnall
His work was sponsored by: DARPA, AFRL

Differential Revision: http://llvm-reviews.chandlerc.com/D3158

llvm-svn: 204621

This pass is a historic remnant and actually causes less efficient code to be
generated in some cases.

llvm-svn: 204620

llvm-svn: 204619

llvm-svn: 204618

This type promotion is replacing a Tablegen pattern and it is already
covered by existing tests.

llvm-svn: 204617

And vice-versa, as long as the types are the same width.

There are a few R600 tests that will cover this.

llvm-svn: 204616

Each GPU family now has its own file.

llvm-svn: 204615

[PPC64LE] ELFv2 ABI updates for the .opd section
The PPC64 Little Endian (PPC64LE) target supports the ELFv2 ABI, and as
such, does not have a ".opd" section.  This is keyed off a _CALL_ELF=2
macro check.

The CALL_ELF check is not clearly documented at this time.  The basis
for usage in this patch is from the gcc thread here:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01144.html

> Adding comment from Uli:
Looks good to me.  I think the old-style JIT doesn't really work
anyway for 64-bit, but at least with this patch LLVM will compile
and link again on a ppc64le host ...

llvm-svn: 204614

Update DataLayout/DescriptionString for ppc64le

Similar LLVM change made in r203664

Testcase included.

llvm-svn: 204613

Summary:
These expressions already worked but weren't tested.

Patch by Robert N. M. Watson and David Chisnall (it was originally two patches)
Their work was sponsored by: DARPA, AFRL

Differential Revision: http://llvm-reviews.chandlerc.com/D3156

llvm-svn: 204612