The current mapping for /section one character options is really bogus.
Map to the correct flags.

llvm-svn: 195774

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

1) Don't start external symbolizer subprocess until we actually try to
   symbolize anything.
2) Allow to turn off external symbolizer by providing empty ?SAN_SYMBOLIZER_PATH
   environment variable.

llvm-svn: 195771

llvm-svn: 195770

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

On a Release build this takes the testcase in pr18055 from 0m3.892s to 0m1.452s.

llvm-svn: 195768

llvm-svn: 195767

Added _WIN32 guards to new platform features. Using correct SetErrorStringWithFormat within Host when LLDB_DISABLE_POSIX is defined. Also fixed an if defined block.

llvm-svn: 195766

llvm-svn: 195763

Changed non-printable characters in the test to the escaped form. Apparently, not all tools display non-printable characters ;)

llvm-svn: 195761

llvm-svn: 195760

llvm-svn: 195759

review!

llvm-svn: 195757

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