Check should be for pointer being NULL, not what it points to.

Also adds a test for this case.

Reviewed By: indygreg

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

llvm-svn: 194965

As the "LLVMInitializeAll*" functions are not available as symbols in
the shared library they can't be used, and as a workaround a list of
the targets is kept and the individual symbols tried. As soon as the
"All"-functions are changed to proper symbols (as opposed to static
inlines in the headers) this hack will be replace with simple calls
to the corresponding "LLVMInitializeAll*" functions.

Reviewed By: indygreg

CC: llvm-commits

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

llvm-svn: 194964

llvm-svn: 194963

llvm-svn: 194962

llvm-svn: 194961

This reverts commit f1d9fe9d04ce93f6d5dcebbd2cb6a07414d7a029.

This was causing PR17964. We need to use thread data before regular data.

llvm-svn: 194960

llvm-svn: 194959

llvm-svn: 194958

This patch modifies LineCol to be a uint32_t.

See http://llvm.org/bugs/show_bug.cgi?id=17957

llvm-svn: 194957

Fixes a typo and changes references to the function clang_displayDiagnostic (which was removed in r96823) to clang_formatDiagnostics.

Patch by David Wiberg

llvm-svn: 194956

Summary:
Definitions we use in public sanitizer headers may
slightly conflict with the ones we use in private sanitizer runtimes.
Moreover, we generally forbid to include any system headers (like <stdint.h>)
in sanitizer runtime headers. This leads to inevitable duplication of selected
interface function declarations, but we decided to live with it.

Reviewers: pcc

Reviewed By: pcc

CC: kcc, llvm-commits

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

llvm-svn: 194955

llvm-svn: 194954

New rules of invalidation/escape of the source buffer of memcpy: the source buffer contents is invalidated and escape while the source buffer region itself is neither invalidated, nor escape.
In the current modeling of memcpy the information about allocation state of regions, accessible through the source buffer, is not copied to the destination buffer and we can not track the allocation state of those regions anymore. So we invalidate/escape the source buffer indirect regions in anticipation of their being invalidated for real later. This eliminates false-positive leaks reported by the unix.Malloc and alpha.cplusplus.NewDeleteLeaks checkers for the cases like

char *f() {
  void *x = malloc(47);
  char *a;
  memcpy(&a, &x, sizeof a);
  return a;
}

llvm-svn: 194953

Fix the problem that the arm_neon.h can't be used in a cpp file. Also fix a minor bug with poly64 name mangling.

llvm-svn: 194952

llvm-svn: 194951

[block-freq] Add BlockFrequency::scale that returns a remainder from the division and make the private scale in BlockFrequency more performant.

This change is the first in a series of changes improving LLVM's Block
Frequency propogation implementation to not lose probability mass in
branchy code when propogating block frequency information from a basic
block to its successors. This patch is a simple infrastructure
improvement that does not actually modify the block frequency
algorithm. The specific changes are:

1. Changes the division algorithm used when scaling block frequencies by
branch probabilities to a short division algorithm. This gives us the
remainder for free as well as provides a nice speed boost. When I
benched the old routine and the new routine on a Sandy Bridge iMac with
disabled turbo mode performing 8192 iterations on an array of length
32768, I saw ~600% increase in speed in mean/median performance.

2. Exposes a scale method that returns a remainder. This is important so
we can ensure that when we scale a block frequency by some branch
probability BP = N/D, the remainder from the division by D can be
retrieved and propagated to other children to ensure no probability mass
is lost (more to come on this).

llvm-svn: 194950

Found by clang-format.

llvm-svn: 194949

llvm-svn: 194948

AnalysisManager. All this method did was assert something and we have
a perfectly good way to trigger that assert from the query path.

llvm-svn: 194947

llvm-svn: 194946

llvm-svn: 194945

llvm-svn: 194944

Generally speaking, control flow paths with error reporting calls are cold.
So far, error reporting calls are calls to perror and calls to fprintf,
fwrite, etc. with stderr as the stream. This can be extended in the future.

The primary motivation is to improve block placement (the cold attribute
affects the static branch prediction heuristics).

llvm-svn: 194943

Implementing this on bigendian platforms could get strange. I added a
target hook, getStackSlotRange, per Jakob's recommendation to make
this as explicit as possible.

llvm-svn: 194942

llvm-svn: 194941

llvm-svn: 194940

This adds a loop rerolling pass: the opposite of (partial) loop unrolling. The
transformation aims to take loops like this:

for (int i = 0; i < 3200; i += 5) {
  a[i]     += alpha * b[i];
  a[i + 1] += alpha * b[i + 1];
  a[i + 2] += alpha * b[i + 2];
  a[i + 3] += alpha * b[i + 3];
  a[i + 4] += alpha * b[i + 4];
}

and turn them into this:

for (int i = 0; i < 3200; ++i) {
  a[i] += alpha * b[i];
}

and loops like this:

for (int i = 0; i < 500; ++i) {
  x[3*i] = foo(0);
  x[3*i+1] = foo(0);
  x[3*i+2] = foo(0);
}

and turn them into this:

for (int i = 0; i < 1500; ++i) {
  x[i] = foo(0);
}

There are two motivations for this transformation:

  1. Code-size reduction (especially relevant, obviously, when compiling for
code size).

  2. Providing greater choice to the loop vectorizer (and generic unroller) to
choose the unrolling factor (and a better ability to vectorize). The loop
vectorizer can take vector lengths and register pressure into account when
choosing an unrolling factor, for example, and a pre-unrolled loop limits that
choice. This is especially problematic if the manual unrolling was optimized
for a machine different from the current target.

The current implementation is limited to single basic-block loops only. The
rerolling recognition should work regardless of how the loop iterations are
intermixed within the loop body (subject to dependency and side-effect
constraints), but the significant restriction is that the order of the
instructions in each iteration must be identical. This seems sufficient to
capture all current use cases.

This pass is not currently enabled by default at any optimization level.

llvm-svn: 194939

CF objects with objc_bridge'ing annotaiton.
// rdar://15454846

llvm-svn: 194938

llvm-svn: 194936

InstCombine, in visitFPTrunc, applies the following optimization to sqrt calls:

  (fptrunc (sqrt (fpext x))) -> (sqrtf x)

but does not apply the same optimization to llvm.sqrt. This is a problem
because, to enable vectorization, Clang generates llvm.sqrt instead of sqrt in
fast-math mode, and because this optimization is being applied to sqrt and not
applied to llvm.sqrt, sometimes the fast-math code is slower.

This change makes InstCombine apply this optimization to llvm.sqrt as well.

This fixes the specific problem in PR17758, although the same underlying issue
(optimizations applied to libcalls are not applied to intrinsics) exists for
other optimizations in SimplifyLibCalls.

llvm-svn: 194935

llvm-svn: 194934

llvm-svn: 194932

llvm-svn: 194931

of ObjectiveC objects to CF types when CF type
has the objc_bridge attribute.

llvm-svn: 194930

This was a source of bugs in the past.

llvm-svn: 194929

Fix ScalarEvolution bugs uncovered by this.

llvm-svn: 194928

llvm-svn: 194927

Per Rafael's review of r194514.

llvm-svn: 194926

This is common in bitfield code.

llvm-svn: 194925

llvm-svn: 194924