llvm-svn: 195806

llvm-svn: 195803

only user was an ancient SCC printing bit of the opt tool which really
should be walking the call graph the same way the CGSCC pass manager
does.

llvm-svn: 195800

With this patch we use simple names for COMDAT sections (like .text or .bss).
This matches the MSVC behavior.

When merging it is the COMDAT symbol that is used to decide if two sections
should be merged, so there is no point in building a fancy name.

This survived a bootstrap on mingw32.

llvm-svn: 195798

class name. I think we're no longer using any compilers with
sufficiently broken ICN for this use case, but I'll watch the bots and
introduce a typedef without a reserved name if any yell at me.

llvm-svn: 195793

PR1860 - We can't save a list of ExtractElement instructions to CSE because some of these instructions
may be removed and optimized in future iterations. Instead we save a list of basic blocks that we need to CSE.

llvm-svn: 195791

llvm-svn: 195790

instructions.

llvm-svn: 195788

In signed arithmetic we could end up with an i64 trip count for an i32 phi.
Because it is signed arithmetic we know that this is only defined if the i32
does not wrap. It is therefore safe to truncate the i64 trip count to a i32
value.

Fixes PR18049.

llvm-svn: 195787

inconsistencies that I'll just need to fix myself as I edit things.

llvm-svn: 195784

doxygen comments, make existing comments doxygen comments etc.

Also, switch commented-out debug helpers to #if-0-ed out debug helpers.

No functionality changed.

llvm-svn: 195783

llvm-svn: 195782

The determination of when we are doing constant pools was being made too
early in the asm printer.

llvm-svn: 195781

I'm adding new functionality in the sample profiler. This will
require more data to be kept around for each function, so I moved
the structure SampleProfile that we keep for each function into
a separate class.

There are no functional changes in this patch. It simply provides
a new home where to place all the new data that I need to propagate
weights through edges.

There are some other name and minor edits throughout.

llvm-svn: 195780

- Fix bug in (vsext (vzext x)) -> (vsext x) in SIGN_EXTEND_IN_REG
  lowering where we need to check whether x is a vector type (in-reg
  type) of i8, i16 or i32; otherwise, that optimization is not valid.

llvm-svn: 195779

This patch adds the counter-part to DominatorTree::getDescendants.
It also fixes a couple of comments I noticed out of date in the
DominatorTree class.

llvm-svn: 195778

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

llvm-svn: 195776

llvm-svn: 195775

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.

llvm-svn: 195773

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

llvm-svn: 195772

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.

llvm-svn: 195769

llvm-svn: 195763

llvm-svn: 195759

review!

llvm-svn: 195757

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. ;]

llvm-svn: 195748

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.

llvm-svn: 195747

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.

llvm-svn: 195731

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.

llvm-svn: 195727

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. =]

llvm-svn: 195722

part of generalizing the call graph infrastructure for the new pass
manager.

llvm-svn: 195718

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.

llvm-svn: 195717

and TRN.
Fix a bug when mixed use of vget_high_u8() and vuzp_u8().

llvm-svn: 195716

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.

llvm-svn: 195715

llvm-svn: 195713

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.

llvm-svn: 195712

llvm-svn: 195711

the Doxygen.

llvm-svn: 195709

spacing around the '*' in pointer types. Will let me use clang-format on
subsequent changes without introducing any noise. No functionality
changed.

llvm-svn: 195708

The dumper was only dumping one pubtypes set and it was /always/ dumping
one pubtypes set even when there were zero sets. Now that the dumper
correctly dumps zero, one, or many sets, we can update this test case to
test for the absolute absence of a set rather than a bogus/accidental
zero-valued set.

llvm-svn: 195706

protection to the same layer.

This is in line with Howard's advice on how best to handle self-move
assignment as he explained on SO[1]. It also ensures that implementing
swap with move assignment continues to work in the case of self-swap.

[1]: http://stackoverflow.com/questions/9322174/move-assignment-operator-and-if-this-rhs

llvm-svn: 195705