llvm-svn: 195756

llvm-svn: 195755

llvm-svn: 195754

Sourcery MIPS toolchain.

llvm-svn: 195753

llvm-svn: 195752

toolchain first and check the path existence. If the path does not
exist build and check a path suffix for Code Sourcery toolchain.

llvm-svn: 195751

llvm-svn: 195750

llvm-svn: 195749

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

Summary:
getStringSplit used to crash, when trying to split a long string
literal containing both printable and unprintable multi-byte UTF-8 characters.

Reviewers: djasper, klimek

Reviewed By: djasper

CC: cfe-commits, klimek

Differential Revision: http://llvm-reviews.chandlerc.com/D2268

llvm-svn: 195728

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

llvm-svn: 195723

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: 195714

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

GNU libc uses '__uptr' as a member name in C mode, conflicting with the
eponymous MSVC pointer modifier keyword.

Detect and mark the token as an identifier when these specific conditions are
met. __uptr will continue to work as a keyword for the remainder of the
translation unit.

Fixes PR17824.

llvm-svn: 195710

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 test code locks mutexes from one thread and unlocks them from a
different one, which is not valid (it's either undefined behaviour or is
required to return an error).

See http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html

llvm-svn: 195707

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

implementation. Silliness, but it'll be a trivial performance
optimization. This should clear up a failure on the vg_leak bot.

llvm-svn: 195704

llvm-svn: 195703

llvm-svn: 195702

changed.

llvm-svn: 195701

r195698 moved the type unit checking up into getOrCreateTypeDIE so
remove the redundant check and fold the functions back together again.

llvm-svn: 195700

whitespace, and a couple of argument name fixes before I start hacking
on this code. No functionality changed here.

llvm-svn: 195699

llvm-svn: 195698

llvm-svn: 195697

It might be possible to eventually use one data structure, but I haven't
looked at the exact criteria used for accelerator tables and pubtypes to
see if there's good reason for the differences between the two or not.

llvm-svn: 195696

This should allow us to cope with newer versions of GCC (and more esoteric
directory layouts).

llvm-svn: 195695

namespace.

llvm-svn: 195693