llvm-svn: 206993

llvm-svn: 206992

llvm-svn: 206991

cl::ParseCommandLineOptions(): Use StringRef to receive sys::path::filename() instead of std::string.

llvm-svn: 206990

llvm-svn: 206989

No functionality change.

llvm-svn: 206988

llvm-svn: 206987

llvm-svn: 206986

llvm-svn: 206985

Summary:
Add new 'let' command to bind arbitrary values into constants.
These constants can then be used in the matcher expressions.

Reviewers: pcc

CC: cfe-commits

Differential Revision: http://reviews.llvm.org/D3383

llvm-svn: 206984

StackDepot is not async-signal-safe; storing a new origin to it can deadlock.

llvm-svn: 206983

Updated to be a bit more const friendly. Also switched the linkage to be static since this function is file-local. No functional changes intended.

llvm-svn: 206982

llvm-svn: 206981

fixes issue http://code.google.com/p/thread-sanitizer/issues/detail?id=57

llvm-svn: 206980

llvm-svn: 206979

llvm-svn: 206978

Initial implementation of -modules-earch-all option, for searching for symbols in non-imported modules.

llvm-svn: 206977

Differential Revision: http://reviews.llvm.org/D3452

llvm-svn: 206976

Pass::doInitialization is supposed to return False when it did not
change the program, not when a fatal error occurs.

llvm-svn: 206975

llvm-svn: 206974

The original messages were:
  "Driver: Honor %INCLUDE% when built with MinGW"
  "Add missing test triples"

The test was still failing on OS X.

llvm-svn: 206973

No functionality change, this parameter was always set to nullptr.

Patch by Robert Matusewicz!

llvm-svn: 206972

For now it contains a single flag, SanitizeAddress, which enables
AddressSanitizer instrumentation of inline assembly.

Patch by Yuri Gorshenin.

llvm-svn: 206971

Patch by Yuri Gorshenin.

llvm-svn: 206970

to prevent memory leaks.

llvm-svn: 206969

This implements the core functionality necessary to remove an edge from
the call graph and correctly update both the basic graph and the SCC
structure. As part of that it has to run a tiny (in number of nodes)
Tarjan-style DFS walk of an SCC being mutated to compute newly formed
SCCs, etc.

This is *very rough* and a WIP. I have a bunch of FIXMEs for code
cleanup that will reduce the boilerplate in this change substantially.
I also have a bunch of simplifications to various parts of both
algorithms that I want to make, but first I'd like to have a more
holistic picture. Ideally, I'd also like more testing. I'll probably add
quite a few more unit tests as I go here to cover the various different
aspects and corner cases of removing edges from the graph.

Still, this is, so far, successfully updating the SCC graph in-place
without disrupting the identity established for the existing SCCs even
when we do challenging things like delete the critical edge that made an
SCC cycle at all and have to reform things as a tree of smaller SCCs.
Getting this to work is really critical for the new pass manager as it
is going to associate significant state with the SCC instance and needs
it to be stable. That is also the motivation behind the return of the
newly formed SCCs. Eventually, I'll wire this all the way up to the
public API so that the pass manager can use it to correctly re-enqueue
newly formed SCCs into a fresh postorder traversal.

llvm-svn: 206968

llvm-svn: 206967

up the stack finishing the exploration of each entries children before
we're finished in addition to accounting for their low-links. Added
a unittest that really hammers home the need for this with interlocking
cycles that would each appear distinct otherwise and crash or compute
the wrong result. As part of this, nuke a stale fixme and bring the rest
of the implementation still more closely in line with the original
algorithm.

llvm-svn: 206966

This completes the porting of r202024 (cpirker "Add AArch64 big endian Target (aarch64_be)") to ARM64.

llvm-svn: 206965

[ARM64] Enable more CodeGen tests for ARM64. The crypto and neon intrinsics tests needed changing slightly due to the naming differences between AArch64 and ARM64.

llvm-svn: 206964

[ARM64] Change inline assembly constraints to be more lax, to match the behaviour of Clang/AArch64 and GCC.

GCC allows sub-64bit values to use the 'r' register constraint.

llvm-svn: 206963

This completes the port of r203918 (cpirker "AArch64_be specific clang target settings") to ARM64.

llvm-svn: 206962

This ensures that r203917 (cpirker "AArch64_be varargs processing for ARM ABI") is ported to ARM64.

llvm-svn: 206961

Differential Revision: http://reviews.llvm.org/D3451

llvm-svn: 206960

parents of an SCC, and add a lookup method for finding the SCC for
a given function. These aren't used yet, but will be used shortly in
some unit tests I'm adding and are really part of the broader intended
interface for the analysis.

llvm-svn: 206959

Windows fix: Need to ensure all APIs are forward decl'd with LLDB_API. If not then frontend linker errors appear due to dllexport differences. There may be some others missing, will commit as I find them.

llvm-svn: 206958

This model is not final and work is still in progress.
However there are substantial improvements on integer tests mainly because of better RAL with new scheduler.

Differential Revision: http://reviews.llvm.org/D3451

llvm-svn: 206957

[LV] Statistics numbers for LoopVectorize introduced: a number of analyzed loops & a number of vectorized loops.
Use -stats to see how many loops were analyzed for possible vectorization and how many of them were actually vectorized.
Patch by Zinovy Nis

Differential Revision: http://reviews.llvm.org/D3438

llvm-svn: 206956

[asan] disable lsan back. :(  -- It appears that quite a few lit tests have leaks and they were not covered by out buildbot

llvm-svn: 206955

resisted this for too long. Just with the basic testing here I was able
to exercise the analysis in more detail and sift out both type signature
bugs in the API and a bug in the DFS numbering. All of these are fixed
here as well.

The unittests will be much more important for the mutation support where
it is necessary to craft minimal mutations and then inspect the state of
the graph. There is just no way to do that with a standard FileCheck
test. However, unittesting these kinds of analyses is really quite easy,
especially as they're designed with the new pass manager where there is
essentially no infrastructure required to rig up the core logic and
exercise it at an API level.

As a minor aside about the DFS numbering bug, the DFS numbering used in
LCG is a bit unusual. Rather than numbering from 0, we number from 1,
and use 0 as the sentinel "unvisited" state. Other implementations often
use '-1' for this, but I find it easier to deal with 0 and it shouldn't
make any real difference provided someone doesn't write silly bugs like
forgetting to actually initialize the DFS numbering. Oops. ;]

llvm-svn: 206954