The problem of r191017 is that when GVN fabricate a val-number for a dead instruction (in order
to make following expr-PRE happy), it forget to fabricate a leader-table entry for it as well.

llvm-svn: 191118

Clean up some simple code quality issues. Bring internal naming
conventions up to current standard, fix inconsistent formatting, and
tidy up a couple of odd contructs.

llvm-svn: 191117

llvm-svn: 191116

llvm-svn: 191115

llvm-svn: 191114

to further work.

llvm-svn: 191113

llvm-svn: 191112

Patch by Dimitry Andric

llvm-svn: 191111

Change posix thread so that it creates a breakpoint stop reason if the breakpoint isn't valid for the current thread but specify should stop to false. Also remove selecting a thread on a breakpoint hit.

llvm-svn: 191110

I cannot think of a test case that reliably triggers this bug.

llvm-svn: 191109

Match reductions starting at binary operation feeding into a phi. The code
handles trees like

 r += v1 + v2 + v3 ...

and

 r += v1
 r += v2
 ...

and

 r *= v1 + v2 + ...

We currently only handle associative operations (add, fadd fast).

The code can now also handle reductions feeding into stores.

 a[i] = v1 + v2 + v3 + ...

The code is currently disabled behind the flag "-slp-vectorize-hor".  The cost
model for most architectures is not there yet.

I found one opportunity of a horizontal reduction feeding a phi in TSVC
(LoopRerolling-flt) and there are several opportunities where reductions feed
into stores.

radar://14607682

llvm-svn: 191108

is no need to go through the driver indirection here, and it clutters
things up as dependencies can sneak in for specific things the driver is
doing.

llvm-svn: 191107

llvm-svn: 191106

llvm-svn: 191105

llvm-svn: 191104

so the Index in/out parameters are pointless (always passed in as 0, always
ignored by the caller).

llvm-svn: 191103

Specifically, allows the unwinder to handle the case where sc.function
gets resolved with a pc that is one past the address range of the function
(consistent with a tail call).  However, there is no matching symbol.

Adds eSymbolContextTailCall to provide callers with control over the scope
of symbol resolution and to allow ResolveSymbolContextForAddress to handle
tail calls since this routine is common to unwind and disassembly.

llvm-svn: 191102

with the closest available 32-bit floating point representation.

llvm-svn: 191101

--gtest_filter was filtering an invalid name for the test.

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

llvm-svn: 191100

This solves the problem of fallback onto ourselves if clang-cl
has been renamed to cl.exe and put on the PATH, as happens with
the VS integration.

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

llvm-svn: 191099

llvm-svn: 191098

llvm-svn: 191097

llvm-svn: 191096

Update the docs for -fms-extensions and -fms-compatibility to try to
clarify the difference between the two.

llvm-svn: 191095

Apart from being more compact and already implemented, this also handles the
case where the parent is null. (It does also ignore all casts, not just
implicit ones, but this is more efficient to test and in the case we care
about---a message in a PseudoObjectExpr---there should only be implicit casts
anyway.

This should fix our internal buildbot.

llvm-svn: 191094

llvm-svn: 191093

llvm-svn: 191092

llvm-svn: 191091

The GEP pattern is what SCEV expander emits for "ugly geps". The latter is what
you get for pointer subtraction in C code. The rest of instcombine already
knows how to deal with that so just canonicalize on that.

llvm-svn: 191090

Make install on lldb was not installing the header files (probably because the file was copied from clang and not updated)

llvm-svn: 191089

llvm-svn: 191088

llvm-svn: 191087

llvm-svn: 191086

That comment is repeated in another function below.

llvm-svn: 191085

[libsanitizer] Pass an explicit template to mktemp. Running mktemp without a template doesn't work on Darwin.

llvm-svn: 191084

llvm-svn: 191083

llvm-svn: 191082

Due to bugs in the interposition of resolver functions on 10.7 and 10.8 both memcpy() and memmove()
were previously intercepted by INTERCEPTOR(memcpy), which led to false positives and crashes (see http://llvm.org/bugs/show_bug.cgi?id=16362)
We choose to use a memmove-like function in both cases. This effectively disables the overlap checks in memcpy(), but the overlaps
aren't possible in practice, because memcpy() and memmove() are the same function on Darwin.

Once the interposition is fixed in 10.9, we'll need to revisit this issue, see https://code.google.com/p/address-sanitizer/issues/detail?id=226

llvm-svn: 191081

llvm-svn: 191080

llvm-svn: 191079