llvm-svn: 176439

Making sure we do not try to copy memory at address 0 - that would make us crash

llvm-svn: 176438

    
LoopConvert isn't properly handling iterators whose dereference operator
returns by value. This test case demonstrates the failure.

See PR15437.

llvm-svn: 176437

    
The Loop-Convert transform was mistransforming loops using 'this' implicitly.
Fixed and added tests.

Fixes PR15411.

llvm-svn: 176436

With [] marking the selected range, clang-format invoked on

    [  ]   int a;

Would so far not reformat anything. With this patch, it formats a
line if its leading whitespace is touched.

llvm-svn: 176435

Patch by Béatrice Creusillet.

llvm-svn: 176434

llvm-svn: 176433

and be sure to apply them whether or not the debugger gave
us a method declaration.

rdar://12565338

llvm-svn: 176432

from a lambda capture when the capture is not trivially-copyable.

rdar://13295759

llvm-svn: 176431

llvm-svn: 176430

with both -static-libgcc and -static on the commandline.

Fix a warning in the latter case due to a backwards short circuiting ||
operator in the driver. No real functionality changed here, just allows
the driver to properly consume -static-libgcc when -static is also
specified.

llvm-svn: 176429

to a subscript operator.

rdar://13332183

llvm-svn: 176428

linking. About to fix a bug here and there was no good test case.

llvm-svn: 176427

llvm-svn: 176426

llvm-svn: 176425

llvm-svn: 176424

Idea by Marshall Clow.

llvm-svn: 176423

llvm-svn: 176422

llvm-svn: 176421

- Generate atomicrmw operations in most of the cases when it's sensible to do
  so.
- Don't crash in several common cases (and hopefully don't crash in more of
  them).
- Add some better tests.

We now generate significantly better code for things like:
_Atomic(int) x;
...
x++;

On MIPS, this now generates a 4-instruction ll/sc loop, where previously it
generated about 30 instructions in two nested loops.  On x86-64, we generate a
single lock incl, instead of a lock cmpxchgl loop (one instruction instead of
ten).

llvm-svn: 176420

llvm-svn: 176419

llvm-svn: 176418

That is where the documentation gets built to.

I'm pretty much clueless about SVN; I would appreciate if someone more
knowledgeable about SVN made the equivalent change.

llvm-svn: 176417

llvm-svn: 176416

llvm-svn: 176415

we are looking at.

llvm-svn: 176414

The VDUP instruction source register doesn't allow a non-constant lane
index, so make sure we don't construct a ARM::VDUPLANE node asking it to
do so.

rdar://13328063
http://llvm.org/bugs/show_bug.cgi?id=13963

llvm-svn: 176413

llvm-svn: 176412

llvm-svn: 176411

Mark them as expand, they are not legal as our backend does not match them.

llvm-svn: 176410

llvm-svn: 176409

This adds minimalistic support for PHI nodes to llvm.objectsize() evaluation

fingers crossed so that it does break clang boostrap again..

llvm-svn: 176408

this is similar to getObjectSize(), but doesnt subtract the offset
tweak the BasicAA code accordingly (per PR14988)

llvm-svn: 176407

llvm-svn: 176406

in a core file if it didn't start at the beginning of a memory segment.
I added more sophisticated kernel location code to DynamicLoaderDarwinKernel
and removed the simple one in ProcessMachCore.  Unfortunately the kernel
DynamicLoader doesn't get a chance to search around in memory unless there's
a hint that this might be a kernel debug session.  It was easy ot make the
kernel location code static in DynamicLoaderDarwinKernel and call it from
ProcessMachCore on the start of the session, so that's what I did.
<rdar://problem/13326647> 

llvm-svn: 176405

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

llvm-svn: 176404

This matters for example in following matrix multiply:

int **mmult(int rows, int cols, int **m1, int **m2, int **m3) {
  int i, j, k, val;
  for (i=0; i<rows; i++) {
    for (j=0; j<cols; j++) {
      val = 0;
      for (k=0; k<cols; k++) {
        val += m1[i][k] * m2[k][j];
      }
      m3[i][j] = val;
    }
  }
  return(m3);
}

Taken from the test-suite benchmark Shootout.

We estimate the cost of the multiply to be 2 while we generate 9 instructions
for it and end up being quite a bit slower than the scalar version (48% on my
machine).

Also, properly differentiate between avx1 and avx2. On avx-1 we still split the
vector into 2 128bits and handle the subvector muls like above with 9
instructions.
Only on avx-2 will we have a cost of 9 for v4i64.

I changed the test case in test/Transforms/LoopVectorize/X86/avx1.ll to use an
add instead of a mul because with a mul we now no longer vectorize. I did
verify that the mul would be indeed more expensive when vectorized with 3
kernels:

for (i ...)
   r += a[i] * 3;
for (i ...)
  m1[i] = m1[i] * 3; // This matches the test case in avx1.ll
and a matrix multiply.

In each case the vectorized version was considerably slower.

radar://13304919

llvm-svn: 176403

Inlining brought a few "null pointer use" false positives, which occur because
the callee defensively checks if a pointer is NULL, whereas the caller knows
that the pointer cannot be NULL in the context of the given call.

This is a first attempt to silence these warnings by tracking the symbolic value
along the execution path in the BugReporter. The new visitor finds the node
in which the symbol was first constrained to NULL. If the node belongs to
a function on the active stack, the warning is reported, otherwise, it is
suppressed.

There are several areas for follow up work, for example:
 - How do we differentiate the cases where the first check is followed by
another one, which does happen on the active stack?

Also, this only silences a fraction of null pointer use warnings. For example, it
does not do anything for the cases where NULL was assigned inside a callee.

llvm-svn: 176402

command source fidelity. // rdar://13066276

llvm-svn: 176401

llvm-svn: 176400