No functional change intended.

Merging up-front rather than delaying this task until later. This just
seems simpler and more efficient (avoiding growing the debug loc list
only to have to skip over those post-merged entries, etc).

llvm-svn: 204679

Add a test to make sure we're doing the right thing for throwing exceptions from deferred functions. This is LWG issue #2186. No change to the library needed.

llvm-svn: 204678

Similar to the implementation for globals in r157167.

Patch by Jingyue Wu.

llvm-svn: 204677

Change the name of the default profile dumped by compiler-rt to
default.profraw.  This distinguishes it more clearly from the
(incompatible) format output by llvm-profdata that is read by clang
-fprofile-instr-use.

llvm-svn: 204676

COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.

To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY.  However, we can only do this if the
string has an external name that we can generate from it's contents.

To be compatible with MSVC, we must use their scheme.  Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.

This fixes PR18248.

N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.  Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.

This reverts commit r204596.

llvm-svn: 204675

As of cl.exe version 18, the special layout rules for structs with 
alignment 16 or greater has been dropped.  This patch drops the behavior 
from clang.  This patch also updates the lit tests to reflect the 
change.

llvm-svn: 204674

llvm-svn: 204673

This is used to avoid relocations in the dwo file by allowing
DW_AT_ranges specified in debug_info.dwo to be relative to this base
address. (r204667 implements the base-relative DW_AT_ranges side of
this)

llvm-svn: 204672

llvm-svn: 204671

plain old CHECKs.

Follow-up to r204633.

llvm-svn: 204670

Update the powerpc64le check to include CALL_ELF=2 check.
This is a testcase follow-up to r204627.
(see also r204614 for CALL_ELF usage).

llvm-svn: 204669

This removes the debug_ranges relocations from debug_info.dwo (but
doesn't implement the DW_AT_GNU_ranges_base which is also necessary for
correct functioning)

llvm-svn: 204668

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