[DebugInfo] Delete dead code, simplify and fix code style for some existing code. No functionality change.

llvm-svn: 192894

llvm-svn: 192893

llvm-svn: 192892

TMPDIR is preferred in Unix.

llvm-svn: 192891

They were failing with -mcpu=atom.

llvm-svn: 192890

llvm-svn: 192889

These were present in a previous version of the MSA spec but are not
present in the published version. There is no hardware that uses these
instructions.

llvm-svn: 192888

This is intended to check how many temporary files would be generated in automated builders.

llvm-svn: 192887

llvm-svn: 192886

Summary:
This fixes a deadlock which happens in lsan
on a large memalign-allocated chunk that resides in lsan's root set.

Reviewers: samsonov, earthdok

Reviewed By: earthdok

CC: llvm-commits

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

llvm-svn: 192885

E.g. (and (sra (i32 x) 31) 2) -> (and (srl (i32 x) 30) 2).

llvm-svn: 192884

When canonicalizing dags according to the rule
(shl (zext (shr X, c1) ), c1) ==> (zext (shl (shr X, c1), c1))

remember to add the new shl dag to the DAGCombiner worklist of nodes.
If we don't explicitly add it to the worklist of nodes to visit, we
may not trigger later on the rule that folds the shift left + logical
shift right into a AND instruction with bitmask.

llvm-svn: 192883

Switch to sign-extension in r192575 caused 7% perf loss on 482.sphinx3.

llvm-svn: 192882

Error handling code for raw_fd_ostream constructor is present, but
never used, because formatted_raw_ostream will always assert on closed
fd's before.

Patch by Peter Zotov

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

llvm-svn: 192881

Define these three instructions in alphabetical order (like the rest of the
file).
No functional change.

llvm-svn: 192880

Solves http://llvm.org/bugs/show_bug.cgi?id=17507

Committed on behalf of alon.mishne@intel.com

llvm-svn: 192879

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

llvm-svn: 192878

llvm-svn: 192877

llvm-svn: 192876

llvm-svn: 192875

llvm-svn: 192874

llvm-svn: 192873

update docs for no_sanitize_thread attribute and blacklist

llvm-svn: 192872

If a function has no_sanitize_thread attribute,
do not instrument memory accesses in it.

llvm-svn: 192871

llvm-svn: 192870

llvm-svn: 192869

__attribute__ (( unavailable )) is for Apple specific builds.  Create a macro
to conditionalise the usage of the macro.  This is to aid in porting the
unwinder to other platforms.

llvm-svn: 192868

to GCC when asked to compile a fortran input.

This fixes a regression with essentially every Fortran compile since we
started rejecting unknown flags. Also moves a mis-classified gfortran
flag into the nicely documented set.

llvm-svn: 192867

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

llvm-svn: 192866

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.

llvm-svn: 192865

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.

llvm-svn: 192864

No functionality changes.

llvm-svn: 192863

function, not the context of the context.

llvm-svn: 192862

if they're a declaration, otherwise they're owned by the compile
unit.

llvm-svn: 192861

Summary:
These are deprecated in VS 2012 according to MSDN.  They don't actually
compile down to any code.  They prevent the compiler from reordering
memory accesses across the barrier, which is what a memory-clobbering
volatile asm does.

Reviewers: echristo

CC: cfe-commits

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

llvm-svn: 192860

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.

llvm-svn: 192859

- Made the dynamic register context for the GDB remote plug-in inherit from the generic DynamicRegisterInfo to avoid code duplication
- Finished up the target definition python setting stuff.
- Added a new "slice" key/value pair that can specify that a register is part of another register:
    { 'name':'eax', 'set':0, 'bitsize':32, 'encoding':eEncodingUint, 'format':eFormatHex, 'slice': 'rax[31:0]' },
- Added a new "composite" key/value pair that can specify that a register is made up of two or more registers:
    { 'name':'d0', 'set':0, 'bitsize':64 , 'encoding':eEncodingIEEE754, 'format':eFormatFloat, 'composite': ['s1', 's0'] },
- Added a new "invalidate-regs" key/value pair for when a register is modified, it can invalidate other registers:
    { 'name':'cpsr', 'set':0, 'bitsize':32 , 'encoding':eEncodingUint, 'format':eFormatHex, 'invalidate-regs': ['r8', 'r9', 'r10', 'r11', 'r12', 'r13', 'r14', 'r15']},
    
This now completes the feature that allows a GDB remote target to completely describe itself.

llvm-svn: 192858

llvm-svn: 192857

llvm-svn: 192856

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

llvm-svn: 192855