llvm-svn: 194988

The maximum number of references the file with NativeReferenceIvarsV1 can
contain is 65534. If a file larger than that is converted to Native format,
the conversion will fail without any error message. This caused a subtle bug
that the LLD would produce a broken executable only when input files contain
too many references.

This issue exists since the RoundTripNativeTest is introduced in r193585. Since
then, it seems that nobody have linked any program having more than 65534
relocations with the LLD. Otherwise we would have found it earlier.

llvm-svn: 194987

Debug info verifier is part of the verifier which is a Function Pass.
Tot currently tries to pull all reachable debug info MDNodes in each function,
which is too time-consuming. The correct fix seems to be separating debug info
verification to its own module pass.

I will disable the debug info verifier until a correct fix is found.

For Bill's testing case, enabling debug info verifier increase compile
time from 11s to 11m.

llvm-svn: 194986

llvm-svn: 194985

llvm-svn: 194984

llvm-svn: 194983

llvm-svn: 194982

llvm-svn: 194981

llvm-svn: 194980

llvm-svn: 194979

llvm-svn: 194978

llvm-svn: 194977

llvm-svn: 194976

llvm-svn: 194975

We used to collect debug info MDNodes in doInitialization and verify them in
doFinalization. That is incorrect since MDNodes can be modified by passes run
between doInitialization and doFinalization.

To fix the problem, we handle debug info MDNodes that can be reached from a
function in runOnFunction (i.e we collect those nodes by calling processDeclare,
processValue and processLocation, and then verify them in runOnFunction).

We handle debug info MDNodes that can be reached from named metadata in
doFinalization. This is in line with how Verifier handles module-level data
(they are verified in doFinalization).

rdar://15472296

llvm-svn: 194974

We used to depend on running processModule before the other public functions
such as processDeclare, processValue and processLocation. We are now relaxing
the constraint by adding a module argument to the three functions and
letting the three functions to initialize the type map. This will be used in
a follow-on patch that collects nodes reachable from a Function.

llvm-svn: 194973

The function isn't strictly at fault but there are callers using it
incorrectly, causing crashes with in-place edits of 64KB or larger files on
Windows.

See PR17960 for details.

llvm-svn: 194972

llvm-svn: 194971

eraseFromParent() invalidates OldName.

llvm-svn: 194970

  lib/Tooling/CompilationDatabase.cpp:275:34: warning: result of comparison against a string literal is unspecified (use strncmp instead) [-Wstring-compare]

This assert() should probably be fixed and added back at some point.

llvm-svn: 194969

FixedCompilationDatabase (FCD) requires that the arguments it consumes after
'--' must not include positional parameters or the argv[0] of the tool. This
patch relaxes those restrictions.

llvm-svn: 194968

This adds -freroll-loops (and -fno-reroll-loops in the usual way) to enable
loop rerolling as part of the optimization pass manager. This transformation
can enable vectorization, reduce code size (or both).

Briefly, loop rerolling can transform a loop 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];
}

into this:

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

Loop rerolling is currently disabled by default at all optimization levels.

llvm-svn: 194967

This adds a boolean member variable to the PassManagerBuilder to control loop
rerolling (just like we have for unrolling and the various vectorization
options). This is necessary for control by the frontend. Loop rerolling remains
disabled by default at all optimization levels.

llvm-svn: 194966

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