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

llvm-svn: 206953

this fires when a user makes mmap with fixed address (see the test)

llvm-svn: 206952

Note, currently we have no 'vararg' support for darwin macros.

llvm-svn: 206951

otherwise it runs for 50 seconds in debug mode

llvm-svn: 206950

AArch64 has feature predicates for NEON, FP and CRYPTO instructions.
This allows the compiler to generate code without using FP, NEON
or CRYPTO instructions.

llvm-svn: 206949

into a helper function. I plan to re-use it for doing incremental
DFS-based updates to the SCCs when we mutate the call graph.

llvm-svn: 206948

These tests shouldn't even try to use the Mips target, but let's make
them not fail when we don't have it while they don't get fixed.

llvm-svn: 206947

Mangle ref-qualifiers like the Nov 2013 CTP.

This fixes PR19361.

llvm-svn: 206946

No functional change.

llvm-svn: 206945

No functional change.

llvm-svn: 206944

No functional change.

llvm-svn: 206943

Fixes compiler complaint about:
src/Unwind/UnwindCursor.hpp:366:25: error: 'libunwind::AbstractUnwindCursor' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]

llvm-svn: 206942

The was working because, given __APPLE__, _LIBUNWIND_BUILD_SJLJ_APIS was set to
__arm__, but other ARM targets not using SJ/LJ will fail to compile.

llvm-svn: 206941

This avoids setting the winlib feature on machines with a lib dir in a
$PATH dir.

llvm-svn: 206940

Darwin and the BSDs define a tagged struct dl_info typedef'd as Dl_info. glibc
and bionic typedef an anonymous struct as Dl_info.

llvm-svn: 206939

the Callee list. This is going to be quite important to prevent removal
from going quadratic. No functionality changed at this point, this is
one of the refactoring patches I've broken out of my initial work toward
mutation updates of the call graph.

llvm-svn: 206938

We previously treated ARM separately from the generic Itanium ABI for
initializing guard variables. This code duplication led to things like
the ARM path missing the memory barrier for threadsafe handling, and a
highly misleading comment about how we were (mis)using the generic ABI
for ARM64 when really it went through the ARM codepath.

This unifies the two code paths. Functionally, this changes the ARM
and ARM64 codepath to use one byte loads instead of 4 and 8,
respectively, and adds the missing atomic acquire to these loads.
Other architectures are unchanged.

llvm-svn: 206937