llvm-svn: 179387

The transform will execute like so:
(A & ~B) == 0 --> (A & B) != 0
(A & ~B) != 0 --> (A & B) == 0

llvm-svn: 179386

1) Driver/output-file-is-dir.c - Checks for object file which can't
be created for Hexagon since assembler is unavailable.
2) PCH/cxx-typeid.cpp - 'typeinfo' include file is unavailable for Hexagon.

llvm-svn: 179385

[libclang] Introduce clang_Location_isInSystemHeader to check if a location resides in a system header.

This is a modified patch provided from Mikołaj Siedlarek!

llvm-svn: 179384

in r179325.  Test case coming shortly on the clang side.
Part of rdar://13453209

llvm-svn: 179383

Also reflow code a bit, no change in functionality.

llvm-svn: 179382

Don't classify idiv/udiv as a reduction operation. Integer division is lossy.
For example : (1 / 2) * 4 != 4/2.

Example:

int a[] = { 2, 5, 2, 2}
int x = 80;

for()
  x /= a[i];

Scalar:
  x /= 2 // = 40
  x /= 5 // = 8
  x /= 2 // = 4
  x /= 2 // = 2

Vectorized:

 <80, 1> / <2,5> //= <40,0>
 <40, 0> / <2,2> //= <20,0>

 20*0 = 0

radar://13640654

llvm-svn: 179381

ASan checks addressability of syscall arguments. TSan does nothing for now.

llvm-svn: 179380

Previously we'd only detect structural errors on the very first level.
This leads to incorrectly balanced braces not being discovered, and thus
incorrect indentation.

This change fixes the problem by:
- changing the parser to use an error state that can be detected
  anywhere inside the productions, for example if we get an eof on
  SOME_MACRO({ some block <eof>
- previously we'd never break lines when we discovered a structural
  error; now we break even in the case of a structural error if there
  are two unwrapped lines within the same line; thus,
  void f() { while (true) { g(); y(); } }
  will still be re-formatted, even if there's missing braces somewhere
  in the file
- still exclude macro definitions from generating structural error;
  macro definitions are inbalanced snippets

llvm-svn: 179379

This time it's the full list scavenged from syscalls.h
Fixed return value type.

llvm-svn: 179378

llvm-svn: 179377

These tests rely specifically on the names of ELF relocations, let alone any
other detail. There's no way they'd work if LLVM was emitting something else by
default.

llvm-svn: 179376

It turns out some platforms (e.g. Windows) lay out their llvm-mc slightly
differently with extra newlines; there was no real reason for the test lines to
be consecutive, so this relaxes the FileCheck.

llvm-svn: 179375

You can't copy an OwningPtr, and move semantics aren't available in C++98.

llvm-svn: 179374

llvm-svn: 179373

The new emacs integration is simpler, does not save the current file
before reformatting and ensures that emacs does not scroll as a result
of formatting.

Also explicitly set the style in clang-format tests to make them more
robust.

llvm-svn: 179372

The ALWAYS_INLINE doesn't have static on POSIX anyways since r178341; the INLINE is only used in .h files, so shouldn't have been 'static' in the first place

llvm-svn: 179371

Fix a disconcerting bug in Value::isUsedInBasicBlock, which gave wrong answers for blocks larger than 3 instrs.

Also add a unit test. PR15727.

llvm-svn: 179370

llvm-svn: 179368

llvm-svn: 179367

llvm-svn: 179366

llvm-svn: 179365

llvm-svn: 179364

llvm-svn: 179363

llvm-svn: 179362

llvm-svn: 179361

This test ensures that relocation type names returned by libObject match
the raw relocation type value.

llvm-svn: 179360

This option expands shown relocations from single line to a dictionary
format:

  Relocation {
    Offset: 0x4
    Type: R_386_32 (1)
    Symbol: sym
    Info: 0x0
  }

llvm-svn: 179359

llvm-svn: 179358

MIPS64EL relocation entries have up to three relocation operations. Because
libObject only exposes a single relocation name, use the concatenation of
the individual relocation type names.

llvm-svn: 179357

This is prep. work for the implementation of optimizeCompare. Many PPC
instructions have 'record' forms (in almost all cases, this means that the RC
bit is set) that cause the result of the instruction to be compared with zero,
and the result of that comparison saved in a predefined condition register. In
order to add the record forms of the instructions without too much
copy-and-paste, the relevant functions have been refactored into multiclasses
which define both the record and normal forms.

Also, two TableGen-generated mapping functions have been added which allow
querying the instruction code for the record form given the normal form (and
vice versa).

No functionality change intended.

llvm-svn: 179356

llvm-svn: 179355

llvm-svn: 179354

When debugging performance regressions we often ask ourselves if the regression
that we see is due to poor isel/sched/ra or due to some micro-architetural
problem.  When comparing two code sequences one good way to rule out front-end
bottlenecks (and other the issues) is to force code alignment. This pass adds
a flag that forces the alignment of all of the basic blocks in the program.

llvm-svn: 179353

By Adam Schnitzer!

llvm-svn: 179352

Before:
  1. Calling 'foo'
    2. Doing something interesting
    3. Returning from 'foo'
  4. Some kind of error here

After:
  1. Calling 'foo'
    2. Doing something interesting
  3. Returning from 'foo'
  4. Some kind of error here

The location of the note is already in the caller, not the callee, so this
just brings the "depth" attribute in line with that.

This only affects plist diagnostic consumers (i.e. Xcode). It's necessary
for Xcode to associate the control flow arrows with the right stack frame.

<rdar://problem/13634363>

llvm-svn: 179351

In this code

  int getZero() {
    return 0;
  }

  void test() {
    int problem = 1 / getZero(); // expected-warning {{Division by zero}}
  }

we generate these arrows:

    +-----------------+
    |                 v
    int problem = 1 / getZero();
                  ^   |
                  +---+

where the top one represents the control flow up to the first call, and the
bottom one represents the flow to the division.* It turns out, however, that
we were generating the top arrow twice, as if attempting to "set up context"
after we had already returned from the call. This resulted in poor
highlighting in Xcode.

* Arguably the best location for the division is the '/', but that's a
  different problem.

<rdar://problem/13326040>

llvm-svn: 179350

llvm-svn: 179349

settings set platform.plugin.darwin-kernel.search-locally-for-kexts true

llvm-svn: 179348

llvm-svn: 179347