whitespace

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195711 91177308-0d34-0410-b5e6-96231b3b80d8
StackMap: Implement support for DirectMemRefOp.

A Direct stack map location records the address of frame index. This
address is itself the value that the runtime requested. This differs
from IndirectMemRefOp locations, which refer to a stack locations from
which the requested values must be loaded. Direct locations can
directly communicate the address if an alloca, while IndirectMemRefOp
handle register spills.

For example:

entry:
  %a = alloca i64...
  llvm.experimental.stackmap(i32 <ID>, i32 <shadowBytes>, i64* %a)

Since both the alloca and stackmap intrinsic are in the entry block,
and the intrinsic takes the address of the alloca, the runtime can
assume that LLVM will not substitute alloca with any intervening
value. This must be verified by the runtime by checking that the stack
map's location is a Direct location type. The runtime can then
determine the alloca's relative location on the stack immediately after
compilation, or at any time thereafter. This differs from Register and
Indirect locations, because the runtime can only read the values in
those locations when execution reaches the instruction address of the
stack map.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195712 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64]Implement 128 bit register copy with NEON.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195713 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Re-format this code with clang-format before making substantial
changes to it. No functionality changed.

You may wonder why on earth touching this code is involved in the pass
manager work as indicated by my lovely '[PM]' tag? Let me tell you
a story.

<redacted>

Yea, it's too long of a story. Let us say that there are yaks, many of
them. I am busy shaving them as fast as I can.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195715 91177308-0d34-0410-b5e6-96231b3b80d8
Refactored the implementation of AArch64 NEON instruction ZIP, UZP
and TRN.
Fix a bug when mixed use of vget_high_u8() and vuzp_u8().

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195716 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Add a really simple trait to the DOTGraphTraitsPass class templates
that lets the analysis and graph types be separate and the graph
computed from the analysis through some arbitrary user-supplied code.

This will allow a call graph to an independent entity from the pass
which creates it which is necessary for the new pass manager.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195717 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Reformat some code with clang-format as I'm going to be editting as
part of generalizing the call graph infrastructure for the new pass
manager.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195718 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Split the CallGraph out from the ModulePass which creates the
CallGraph.

This makes the CallGraph a totally generic analysis object that is the
container for the graph data structure and the primary interface for
querying and manipulating it. The pass logic is separated into its own
class. For compatibility reasons, the pass provides wrapper methods for
most of the methods on CallGraph -- they all just forward.

This will allow the new pass manager infrastructure to provide its own
analysis pass that constructs the same CallGraph object and makes it
available. The idea is that in the new pass manager, the analysis pass's
'run' method returns a concrete analysis 'result'. Here, that result is
a 'CallGraph'. The 'run' method will typically do only minimal work,
deferring much of the work into the implementation of the result object
in order to be lazy about computing things, but when (like DomTree)
there is *some* up-front computation, the analysis does it prior to
handing the result back to the querying pass.

I know some of this is fairly ugly. I'm happy to change it around if
folks can suggest a cleaner interim state, but there is going to be some
amount of unavoidable ugliness during the transition period. The good
thing is that this is very limited and will naturally go away when the
old pass infrastructure goes away. It won't hang around to bother us
later.

Next up is the initial new-PM-style call graph analysis. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195722 91177308-0d34-0410-b5e6-96231b3b80d8
CMake : optionaly enable LLVM to be compiled with -std=c++11 (default: off)

In some case, it may be required to build LLVM in C++11 mode, as some the subprojects (like lldb) requires it.

This mimics the autoconf behaviour.

However, given the discussions on the switch to C++11 of the codebase, this behaviour should evolve to default to C++11 with some checks of the compiler capabilities.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195727 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Fix incorrect use of RISBG for a zero-extended right shift

We would wrongly transform the testcase into the equivalent of an AND with 1.
The problem was that, when testing whether the shifted-in bits of the right
shift were significant, we used the width of the final zero-extended result
rather than the width of the shifted value.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195731 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Factor the overwhelming majority of the interface boiler plate out
of the two analysis managers into a CRTP base class that can be shared
and re-used in building any analysis manager. This will in turn simplify
adding yet another analysis manager to the system.

The base class provides all of the interface sugar for the analysis
manager delegating the functionality back through DerivedT methods which
operate on simple pass IDs. It also provides the pass registration,
storage, and lookup system which is common across the various
formulations of analysis managers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195747 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Remove four extraneous 'typename's that Clang (in C++11 mode) is
happy with but GCC complains about. I'm assuming both compilers are
correct and these are optional in C++11 because I'm too tired to read
the standard. ;]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195748 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Fix a stale comment after my last refactoring spoted by Joey in
review!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195757 91177308-0d34-0410-b5e6-96231b3b80d8
Darwin-ARM: use movw/movt for static relocations

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195759 91177308-0d34-0410-b5e6-96231b3b80d8
Rename DwarfException methods so the new names are consistent with DwarfDebug and the style guide

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

Short description.

This issue is about case of treating pointers as integers.
We treat pointers as different if they references different address space.
At the same time, we treat pointers equal to integers (with machine address
width). It was a point of false-positive. Consider next case on 32bit machine:

void foo0(i32 addrespace(1)* %p)
void foo1(i32 addrespace(2)* %p)
void foo2(i32 %p)

foo0 != foo1, while
foo1 == foo2 and foo0 == foo2.

As you can see it breaks transitivity. That means that result depends on order
of how functions are presented in module. Next order causes merging of foo0
and foo1: foo2, foo0, foo1
First foo0 will be merged with foo2, foo0 will be erased. Second foo1 will be
merged with foo2.
Depending on order, things could be merged we don't expect to.

The fix:
Forbid to treat any pointer as integer, except for those, who belong to address space 0.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195769 91177308-0d34-0410-b5e6-96231b3b80d8
Add return to DIType::Verify

Code scanner ran by Sylvestre Ledru got a no_return bug
in DebugInfo.cpp. Adding the return statements that
should be there.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195772 91177308-0d34-0410-b5e6-96231b3b80d8
PR18060 - When we RAUW values with ExtractElement instructions in some cases
we generate PHI nodes with multiple entries from the same basic block but
with different values. Enabling CSE on ExtractElement instructions make sure
that all of the RAUWed instructions are the same.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195773 91177308-0d34-0410-b5e6-96231b3b80d8
Fix spurious return introduced by my earlier patch to DebugInfo

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195775 91177308-0d34-0410-b5e6-96231b3b80d8
DwarfDebug: Include type units in accelerator tables.

Since type units aren't in the CUMap, use the DwarfUnits list to iterate
over units for tasks such as accelerator table building.

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