llvm-svn: 194546

llvm-svn: 194545

Implement a "memory find" command for LLDB

This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in
mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r

llvm-svn: 194544

llvm-svn: 194543

This patch reapplies r193676 with an additional fix for the Hexagon backend. The
SystemZ backend has already been fixed by r194148.

The Type Legalizer recognizes that VSELECT needs to be split, because the type
is to wide for the given target. The same does not always apply to SETCC,
because less space is required to encode the result of a comparison. As a result
VSELECT is split and SETCC is unrolled into scalar comparisons.

This commit fixes the issue by checking for VSELECT-SETCC patterns in the DAG
Combiner. If a matching pattern is found, then the result mask of SETCC is
promoted to the expected vector mask type for the given target. Now the type
legalizer will split both VSELECT and SETCC.

This allows the following X86 DAG Combine code to sucessfully detect the MIN/MAX
pattern. This fixes PR16695, PR17002, and <rdar://problem/14594431>.

Reviewed by Nadav

llvm-svn: 194542

pattern in use here. Addresses review feedback from Sean (thanks!) and
others.

llvm-svn: 194541

expression that is not a zero literal, in C. Patch by Ivan A. Kosarev!

llvm-svn: 194540

llvm-svn: 194539

more smarts in it. This is where most of the interesting logic that used
to live in the implicit-scheduling-hackery of the old pass manager will
live.

Like the previous commits, note that this is a very early prototype!
I expect substantial changes before this is ready to use.

The core of the design is the following:

- We have an AnalysisManager which can be used across a series of
  passes over a module.
- The code setting up a pass pipeline registers the analyses available
  with the manager.
- Individual transform passes can check than an analysis manager
  provides the analyses they require in order to fail-fast.
- There is *no* implicit registration or scheduling.
- Analysis passes are different from other passes: they produce an
  analysis result that is cached and made available via the analysis
  manager.
- Cached results are invalidated automatically by the pass managers.
- When a transform pass requests an analysis result, either the analysis
  is run to produce the result or a cached result is provided.

There are a few aspects of this design that I *know* will change in
subsequent commits:
- Currently there is no "preservation" system, that needs to be added.
- All of the analysis management should move up to the analysis library.
- The analysis management needs to support at least SCC passes. Maybe
  loop passes. Living in the analysis library will facilitate this.
- Need support for analyses which are *both* module and function passes.
- Need support for pro-actively running module analyses to have cached
  results within a function pass manager.
- Need a clear design for "immutable" passes.
- Need support for requesting cached results when available and not
  re-running the pass even if that would be necessary.
- Need more thorough testing of all of this infrastructure.

There are other aspects that I view as open questions I'm hoping to
resolve as I iterate a bit on the infrastructure, and especially as
I start writing actual passes against this.
- Should we have separate management layers for function, module, and
  SCC analyses? I think "yes", but I'm not yet ready to switch the code.
  Adding SCC support will likely resolve this definitively.
- How should the 'require' functionality work? Should *that* be the only
  way to request results to ensure that passes always require things?
- How should preservation work?
- Probably some other things I'm forgetting. =]

Look forward to more patches in shorter order now that this is in place.

llvm-svn: 194538

llvm-svn: 194537

pair, and a couple of pair-like implementation detail types.  The
C++98/03 and 11 standards all specify that the copy constructor of
pair<int, int> is trivial. However as libc++ tracked the draft C++11
standard over the years, this copy constructor became non-trivial, and
then just recently was corrected back to trivial for C++11.

Unfortunately (for libc++1) the Itanium ABI specifies different calling
conventions for trivial and non-trivial copy constructors.  Therefore
currently the C++03 libc++ copy constructor for pair<int, int> is ABI
incompatible with the C++11 libc++ copy constructor for pair<int, int>.
This is Bad(tm).   This patch corrects the situation by making this copy
constructor trivial in C++03 mode as well.

Just in case it is needed for an incomplete C++11 compiler, libc++
retains the ability to support pair with rvalue references, but without
defaulted special members.  However the pair needs non-trivial special
members to implement this special case, (as it did when clang was in
this place a couple of years ago).

During this work a bug was also found and fixed in
is_trivially_constructible.

And there is a minor drive-by fix in <__config> regarding
__type_visibility__.

A test is updated to ensure that the copy constructor of pair<int, int>
is trivial in both C++03 and C++11.  This test will necessarily fail for
a compiler that implements rvalue references but not defaulted special
members.

llvm-svn: 194536

Removing llvm::huge_vald and llvm::huge_vall because they are not currently used, and HUGE_VALD does not appear to be supported everywhere anyways.

llvm-svn: 194535

unittests/Tooling/ToolingTest.cpp: Suppress new tests on win32, due to handling of virtual file, such "/a.cc".

llvm-svn: 194534

Patch reviewed by Reid Kleckner and Jim Grosbach.

llvm-svn: 194533

on inferred property attribute under
 -objcmt-ns-nonatomic-iosonly  option.
// rdar://15442742

llvm-svn: 194532

SBThread::GetExtendedBacktraceThread to make it more clear what is
being returned.

llvm-svn: 194531

llvm-svn: 194530

I still don't know how to refer to the fixed operands symbolically. I
plan to look into it.

llvm-svn: 194529

print the name of the function on which the dependence analysis is performed
such that changes to the testcase are easier to review.

llvm-svn: 194528

llvm-svn: 194527

llvm-svn: 194526

Fold (iszero(A&K1) | iszero(A&K2)) ->  (A&(K1|K2)) != (K1|K2) if we know that K1 and K2 are 'one-hot' (only one bit is on).

llvm-svn: 194525

FoldBranchToCommonDest merges branches into a single branch with or/and of the condition. It has a heuristics for estimating when some of the dependencies are processed by out-of-order processors. This patch adds another rule to the heuristics that says that if the "BonusInstruction" that we speculatively execute is used by the condition of the second branch then it is okay to hoist it. This change exposes more opportunities for other passes to transform the code. It does not matter that much that we if-convert the code because the selectiondag builder splits or/and branches into multiple branches when profitable.

llvm-svn: 194524

llvm-svn: 194523

argument was not being passed in $f14.
 

llvm-svn: 194522

llvm-svn: 194521

The problem was that given

template<typename T>
struct foo {
  ~foo() {}
};
template class foo<int>;

We would produce a alias, creating a comdat with D0 and D1, since the symbols
have to be weak. Another TU is not required to have a explicit template
instantiation definition or an explict template instantiation declaration and
for

template<typename T>
struct foo {
  ~foo() {}
};
foo<int> a;

we would produce a comdat with only one symbol in it.

llvm-svn: 194520

 

llvm-svn: 194519

llvm-svn: 194515

Add user-supplied C runtime and compiler-rt library functions to
llvm.compiler.used to protect them from premature optimization by
passes like -globalopt and -ipsccp.  Calls to (seemingly unused)
runtime library functions can be added by -instcombine and instruction
lowering.

Patch by Duncan Exon Smith, thanks!

Fixes <rdar://problem/14740087>

llvm-svn: 194514

llvm-svn: 194513

The system LDM and STM instructions can't usually writeback to the base
register. The one exception is when an LDM is actually an exception-return
(i.e. contains PC in the register list).

(There's already a test that "ldm sp!, {r0-r3, pc}^" works, which is why there
is no positive test).

rdar://problem/15223374

llvm-svn: 194512

 

llvm-svn: 194511

 

llvm-svn: 194510

This commit significantly speeds up both bytecode and native
builds of LLVM clients (from ~20 second to sub-second link time),
and allows to invoke LLVM functions from OCaml toplevel.

The behavior for --disable-shared builds is unchanged.

llvm-svn: 194509

llvm-svn: 194508

is further restricted in legacy runtime to deployment target
of 10.7 and later. // rdar://15363492

llvm-svn: 194507

Constant merge can merge a constant with implicit alignment with one that has
explicit alignment. Before this change it was assuming that the explicit
alignment was higher than the implicit one, causing the result to be under
aligned in some cases.

Fixes pr17815.

Patch by Chris Smowton!

llvm-svn: 194506

llvm-svn: 194505

Extended moduleImport test to test a module with more than one path component.  This required a change to the includes test, because of the change to the headers.

llvm-svn: 194504