Now that the LiveDebugVariables pass is running *after* register
coalescing, the ConnectedVNInfoEqClasses class needs to deal with
DBG_VALUE instructions.

This only comes up when rematerialization during coalescing causes the
remaining live range of a virtual register to separate into two
connected components.

llvm-svn: 182592

llvm-svn: 182590

llvm-svn: 182588

Also removes an unused function.

llvm-svn: 182587

Lets us use a SetVector instead of an explicit set + vector combination.

llvm-svn: 182586

Setting the default value (fixes CRT assertions about uninitialized variable use when doing debug MSVC builds), and fixing coding style.

llvm-svn: 182585

The error was:
error: non-constant-expression cannot be narrowed from type 'long long' to 'long' in initializer list [-Wc++11-narrowing]
        MI.getOperand(6).getImm() & 0x1F,

llvm-svn: 182584

llvm-svn: 182564

This should bring the valgrind bot back to life.

llvm-svn: 182561

llvm-svn: 182560

These are not needed since we added the $ORIGIN based rpath.

Fixes pr12517.

llvm-svn: 182559

llvm-svn: 182558

[objc-arc] Fixed number of prefixing slashes in some comments in a function from 3 to 2 to match the rest of ObjCARCOpts.

llvm-svn: 182557

llvm-svn: 182556

Updated the comments of APInt.h to match the llvm style guide and be consistent. No functionality change.

llvm-svn: 182555

API with my 176880 revision.  If a bad Triple is passed in it can also assert.
In this case too it should just return 0 to indicate failure to create the
disassembler.

rdar://13955214

llvm-svn: 182542

llvm-svn: 182536

llvm-svn: 182534

There were bits & pieces of code lying around that may've given the
impression that debug info metadata supported the possibility that a
subprogram's type could be specified by a non-subroutine type describing
the return type of a void function. This support was incomplete &
unnecessary. Asserts & API have been changed to make the desired usage
more clear.

llvm-svn: 182532

llvm-svn: 182531

llvm-svn: 182527

llvm-svn: 182526

Currently the fast-isel table generator recognizes registers, register
classes, and immediates for source pattern operands.  ValueType
operands are not recognized.  This is not a problem for existing
targets with fast-isel support, but will not work for targets like
PowerPC and SPARC that use types in source patterns.

The proposed patch allows ValueType operands and treats them in the
same manner as register classes.  There is no convenient way to map
from a ValueType to a register class, but there's no need to do so.
The table generator already requires that all types in the source
pattern be identical, and we know the register class of the output
operand already.  So we just assign that register class to any
ValueType operands we encounter.

No functional effect on existing targets.  Testing deferred until the
PowerPC target implements fast-isel.

llvm-svn: 182512

Using PatLeaf rather than ImmLeaf when defining immediate predicates
prevents simple patterns using those predicates from being recognized
for fast instruction selection.  This patch replaces the immSExt16
PatLeaf predicate with two ImmLeaf predicates, imm32SExt16 and
imm64SExt16, allowing a few more patterns to be recognized (ADDI,
ADDIC, MULLI, ADDI8, and ADDIC8).  Using the new predicates does not
help for LI, LI8, SUBFIC, and SUBFIC8 because these are rejected for
other reasons, but I see no reason to retain the PatLeaf predicate.

No functional change intended, and thus no test cases yet.  This is
preliminary work for enabling fast-isel support for PowerPC.  When
that support is ready, we'll be able to test this function.

llvm-svn: 182510

We are not working on a DAG and I ran into a number of problems when I enabled the vectorizations of 'diamond-trees' (trees that share leafs).
* Imroved the numbering API.
* Changed the placement of new instructions to the last root.
* Fixed a bug with external tree users with non-zero lane.
* Fixed a bug in the placement of in-tree users.

llvm-svn: 182508

llvm-svn: 182507

llvm-svn: 182503

The earlier change list introduced the following inst combines:
B * (uitofp i1 C) —> select C, B, 0
A * (1 - uitofp i1 C) —> select C, 0, A
select C, 0, B + select C, A, 0 —> select C, A, B

Together these 3 changes would simplify :
A * (1 - uitofp i1 C) + B * uitofp i1 C 
down to :
select C, B, A

In practice we found that the first two substitutions can have a
negative effect on performance, because they reduce opportunities to
use FMA contractions; between the two options FMAs are often the
better choice.  This change list amends the previous one to enable
just these inst combines:

select C, B, 0 + select C, 0, A —> select C, B, A
A * (1 - uitofp i1 C) + B * uitofp i1 C —> select C, B, A

llvm-svn: 182499

llvm-svn: 182496

llvm-svn: 182495

llvm-svn: 182493

constructors.  No functional change.
Part of rdar://12906217

llvm-svn: 182490

This makes StringMap<> more compatible with std::map<std::string, ...>.

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

llvm-svn: 182487

Take #2 on fixing PR15977.

llvm-svn: 182486

The Value pointers we store in the induction variable list can be RAUW'ed by a
call to SCEVExpander::expandCodeFor, use a TrackingVH instead. Do the same thing
in some other places where we store pointers that could potentially be RAUW'ed.

Fixes PR16073.

llvm-svn: 182485

llvm-svn: 182482

Fixes a use of uninitialized memory found by asan and valgind.

llvm-svn: 182480

Addresses a review comment from Ulrich Weigand.  No functional change intended.

I'm not sure whether the old TODO that this patch touches still holds,
but that's something we'd get to when adding a targetted scheduling
description.

llvm-svn: 182474

llvm-svn: 182464

The original version of the pass could underestimate the length of a backward
branch in cases like:

    alignment to N bytes or more
    ...
    relaxable branch A
    ...
 foo: (aligned to M<N bytes)
    ...
 bar: (aligned to N bytes)
    ...
    relaxable branch B to foo

We don't add any misalignment gap for "bar" because N bytes of alignment
had already been reached earlier in the function.  In this case, assuming
that A is relaxed can push "foo" closer to "bar", and make B appear to be
in range.  Similar problems can occur for forward branches.

I don't think it's possible to create blocks with mixed alignments as
things stand, not least because we haven't yet defined getPrefLoopAlignment()
for SystemZ (that would need benchmarking).  So I don't think we can test
this yet.

Thanks to Rafael Espíndola for spotting the bug.

llvm-svn: 182460