Allow repeated registration again.

Our use of -fvisibility-inlines-hidden means we cannot check function pointers
against non null values.

Unfortunately, we also cannot assert that the callbacks are initialized only
once. The problem is that lldb has multiple subsystems that need to call this
and they don't have a unique initialization order.

Thanks to Sean Callanan for reporting it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192835 91177308-0d34-0410-b5e6-96231b3b80d8
DIEHash: Include the trailing zero byte after the children of a DIE

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192836 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for the VSX target attribute. No functional change
as we don't actually use it to emit any code yet.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192837 91177308-0d34-0410-b5e6-96231b3b80d8
Remove ambiguity introduced in r192836

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192840 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Add support for NEON scalar absolute value instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192842 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Add support for NEON scalar negate instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192843 91177308-0d34-0410-b5e6-96231b3b80d8
Update test case due to DIE hashing in r192836

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

The C API currently allows to dump values (LLVMDumpValue), but a similar method for types was not exported.

Patch by Peter Zotov

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192852 91177308-0d34-0410-b5e6-96231b3b80d8
Invert arguments to ASSERT_EQ to match gtest diagnostic printing

GTest assumes the left hand side of the assert is the expectation and
the right hand side is the test result. It's easier to read gtest
failures when these things are ordered correctly.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192854 91177308-0d34-0410-b5e6-96231b3b80d8
DIEHash: Use DW_FORM_sdata for integers, per spec.

This allows us to produce the same hash as GCC for at least some simple
examples.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192855 91177308-0d34-0410-b5e6-96231b3b80d8
DIEHash: Include the type's context in the type hash.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192856 91177308-0d34-0410-b5e6-96231b3b80d8
Re-commit r192758 - MC: quote tricky symbol names in asm output

The reason this got reverted was that the @feat.00 symbol which was emitted
for every TU became quoted, and on cygwin/mingw we use the gas assembler which
couldn't handle the quotes.

This commit fixes the problem by only emitting @feat.00 for win32, where we use
clang -cc1as to assemble. gas would just drop this symbol anyway, so there is no
loss there.

With @feat.00 gone, there shouldn't be quoted symbols showing up on cygwin since
it uses the Itanium ABI, which doesn't put these funny characters in symbols.

> Because of win32 mangling, we produce symbol and section names with
> funny characters in them, most notably @ characters.
>
> MC would choke on trying to parse its own assembly output. This patch addresses
> that by:
>
> - Making @ trigger quoting of symbol names
> - Also quote section names in the same way
> - Just parse section names like other identifiers (to allow for quotes)
> - Don't assume @ signifies a symbol variant if it is in a string.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192859 91177308-0d34-0410-b5e6-96231b3b80d8
Add the subprogram DIEs to the context they're created with only
if they're a declaration, otherwise they're owned by the compile
unit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192861 91177308-0d34-0410-b5e6-96231b3b80d8
[projects/test-suite] White space and long line fixes.

No functionality changes.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192863 91177308-0d34-0410-b5e6-96231b3b80d8
Expose install_fatal_error_handler() through the C API.

I expose the API with some caveats:

- The C++ API involves a traditional void* opaque pointer for the fatal 
error callback.  The C API doesn’t do this.  I don’t think that the void* 
opaque pointer makes any sense since this is a global callback - there will 
only be one of them.  So if you need to pass some data to your callback, 
just put it in a global variable.

- The bindings will ignore the gen_crash_diag boolean.  I ignore it because 
(1) I don’t know what it does, (2) it’s not documented AFAIK, and (3) I 
couldn’t imagine any use for it.  I made the gut call that it probably 
wasn’t important enough to expose through the C API.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192864 91177308-0d34-0410-b5e6-96231b3b80d8
According to the dwarf standard pubnames and pubtypes for languages
like C++ should be the fully qualified names for the type.

Add a routine that does a language specific context walk to build
up the qualified name and use it when we add types/names to the
tables. Expand the gnu pubnames testcase as it's the most complex
to make sure that qualified types are also being added.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192865 91177308-0d34-0410-b5e6-96231b3b80d8
x86: Move bitcasts outside concat_vector.

Consider the following:

typedef unsigned short ushort4U __attribute__((ext_vector_type(4),
aligned(2)));
typedef unsigned short ushort4 __attribute__((ext_vector_type(4)));
typedef unsigned short ushort8 __attribute__((ext_vector_type(8)));
typedef int int4 __attribute__((ext_vector_type(4)));

int4 __bbase_cvt_int(ushort4 v) {
  ushort8 a;
  a.lo = v;
  return _mm_cvtepu16_epi32(a);
}

This generates the, not unreasonable, IR:
define <4 x i32> @foo0(double %v.coerce) nounwind ssp {
  %tmp = bitcast double %v.coerce to <4 x i16>
  %tmp1 = shufflevector <4 x i16> %tmp, <4 x i16> undef, <8 x i32> <i32
  %0, i32 1, i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef>
  %tmp2 = tail call <4 x i32> @llvm.x86.sse41.pmovzxwd(<8 x i16> %tmp1)
  ret <4 x i32> %tmp2
}

The problem is when type legalization gets hold of the v4i16. It
legalizes that by spilling to the stack, then doing a zero-extending
load. Things go even more silly from there, ending up with something
like:
_foo0:
  movsd %xmm0, -8(%rsp)       <== Spill to the stack.
  movq  -8(%rsp), %xmm0       <== Reload it right back out.
  pmovzxwd  %xmm0, %xmm1      <== Here's what we actually asked for.
  pblendw $1, %xmm1, %xmm0    <== We don't need this at all
  pmovzxwd  %xmm0, %xmm0      <== We already did this
  ret

The v8i8 to v8i16 zext intrinsic gives even worse results, with two
table lookups via pshufb instructions(!!).

To avoid all that, we can move the bitcasting until after we've formed
the wider (legal) vector type. Then our normal codegen flows along
nicely and we get the expected:
_foo0:
  pmovzxwd  %xmm0, %xmm0
  ret

rdar://15245794

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192866 91177308-0d34-0410-b5e6-96231b3b80d8
tsan: implement no_sanitize_thread attribute
If a function has no_sanitize_thread attribute,
do not instrument memory accesses in it.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192871 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-c: Return NULL from LLVMGetFirstTarget instead of asserting

If no targets are registered, LLVMGetFirstTarget currently fails with
an assertion. This patch makes it return NULL instead, similarly to
how LLVMGetNextTarget would.

Patch by Peter Zotov

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192878 91177308-0d34-0410-b5e6-96231b3b80d8
Changing DebugInfoFinder to iterate over all the compile units.
Solves http://llvm.org/bugs/show_bug.cgi?id=17507

Committed on behalf of alon.mishne@intel.com

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