Use std::unique_ptr to handle ownership of DwarfUnits in DwarfFile.

So Chandler - how about those range algorithms? (would really love a
dereferencing range adapter for this sort of stuff)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206921 91177308-0d34-0410-b5e6-96231b3b80d8
Change the prototype for MCContext::FatalError() so it can be called
from places like MCCodeEmitter() in the MC backend when the
MCContext is const.

I was going to use this in my change for r206669 but Jim convinced
me to use an assert there. But this still is a good tweak.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206923 91177308-0d34-0410-b5e6-96231b3b80d8
[docs] Add a note to docs/README.txt

Added note to docs/README.txt on how to check the reachibility of
external links in the documentation.

Patch by Dan Liew!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206924 91177308-0d34-0410-b5e6-96231b3b80d8
Push memory ownership of DwarfUnits into clients of DwarfFile.

This prompted me to push references through most of DwarfDebug. Sorry
for the churn.

Honestly it's a bit silly that we're passing around units all over the
place like that anyway and I think it's mostly due to the DIE attribute
adding utility functions being utilities in DwarfUnit. I should have
another go at moving them out of DwarfUnit...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206925 91177308-0d34-0410-b5e6-96231b3b80d8
Requisite reformatting for previous commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206927 91177308-0d34-0410-b5e6-96231b3b80d8
Fix test/CodeGen/arm.ll

The 'CHECK: add' line was occasionally matching against the filename,
breaking the subsequent CHECK-NOT.  Also use CHECK-LABEL.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206936 91177308-0d34-0410-b5e6-96231b3b80d8
[LCG] Switch the Callee sets to be DenseMaps pointing to the index into
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206938 91177308-0d34-0410-b5e6-96231b3b80d8
[LCG] Hoist the logic for forming a new SCC from the top of the DFSStack
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206948 91177308-0d34-0410-b5e6-96231b3b80d8
[ARM64] Enable feature predicates for NEON / FP / CRYPTO.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206949 91177308-0d34-0410-b5e6-96231b3b80d8
Integrated assbemler, macros: added 'vararg' argument qualifier support.
Note, currently we have no 'vararg' support for darwin macros.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206951 91177308-0d34-0410-b5e6-96231b3b80d8
X86Disassembler - fixed a bug in immediate print


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206953 91177308-0d34-0410-b5e6-96231b3b80d8
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and
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. ;]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206954 91177308-0d34-0410-b5e6-96231b3b80d8
[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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206956 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Silvermont new scheduler model
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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206957 91177308-0d34-0410-b5e6-96231b3b80d8
[LCG] Add some accessor methods to the SCC to allow iterating over the
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206959 91177308-0d34-0410-b5e6-96231b3b80d8
Fixing typos in commit r206957

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206960 91177308-0d34-0410-b5e6-96231b3b80d8
[ARM64] Add a big endian version of the ARM64 target machine, and update all users.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206965 91177308-0d34-0410-b5e6-96231b3b80d8
[LCG] Implement Tarjan's algorithm correctly this time. We have to walk
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206966 91177308-0d34-0410-b5e6-96231b3b80d8
[ARM64] Fix formatting.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206967 91177308-0d34-0410-b5e6-96231b3b80d8
[LCG] Add the first round of mutation support to the lazy call graph.
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206968 91177308-0d34-0410-b5e6-96231b3b80d8