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

Allow LLVM to take advantage of shift instructions that set the ZF flag,
making instructions that test the destination superfluous.

llvm-svn: 182454

R600ISelLowering.cpp: Avoid "using namespace Intrinsic;" to appease MSC. Specify namespaces explicitly here.

MSC is confused about "memcpy" between <cstring> and llvm::Intrinsic::memcpy, when llvm::Intrinsic were exposed.

llvm-svn: 182452

llvm-svn: 182451

Create an FPOW SDNode opcode def in the target independent .td file rather than in a specific backend.

llvm-svn: 182450

the C API to provide their own way of allocating JIT memory (both code 
and data) and finalizing memory permissions (page protections, cache 
flush).

llvm-svn: 182448

Should fix the cmake bots that were already building R600.

llvm-svn: 182447

This should hopefully fix
http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32

llvm-svn: 182446

llvm-svn: 182444

llvm-svn: 182443

The r600 backend has been in tree for some time now. Marking it as
non-experimental to avoid accidental breakage.

llvm-svn: 182442

a RegScavenger object on it's own.
 

llvm-svn: 182430

llvm-svn: 182424

Solaris doesn't have an endian.h header, but SPARC is the only
big-endian architecture that runs Solaris, so just use that to detect
endianness at compile time.

llvm-svn: 182419

libExecutionEngine. Move method implementations that aren't specific to 
allocation out of SectionMemoryManager and into RTDyldMemoryManager.

This is in preparation for exposing RTDyldMemoryManager through the C 
API.

This is a fixed version of r182407 and r182411. That first revision 
broke builds because I forgot to move the conditional includes of 
various POSIX headers from SectionMemoryManager into 
RTDyldMemoryManager. Those includes are necessary because of how 
getPointerToNamedFunction works around the glibc libc_nonshared.a thing. 
The latter revision still broke things because I forgot to include 
llvm/Config/config.h.

llvm-svn: 182418

llvm-svn: 182415

Fix busted comment. This conditional include block used to be in SectionMemoryManager, but is now in RTDyldMemoryManager.

llvm-svn: 182412

libExecutionEngine. Move method implementations that aren't specific to 
allocation out of SectionMemoryManager and into RTDyldMemoryManager.

This is in preparation for exposing RTDyldMemoryManager through the C 
API.

This is a fixed version of r182407. That revision broke builds because I 
forgot to move the conditional includes of various POSIX headers from 
SectionMemoryManager into RTDyldMemoryManager. Those includes are 
necessary because of how getPointerToNamedFunction works around the 
glibc libc_nonshared.a thing.

llvm-svn: 182411

llvm-svn: 182409

the C API to provide their own way of allocating JIT memory (both code 
and data) and finalizing memory permissions (page protections, cache 
flush).

llvm-svn: 182408

libExecutionEngine. Move method implementations that aren't specific to 
allocation out of SectionMemoryManager and into RTDyldMemoryManager.

This is in preparation for exposing RTDyldMemoryManager through the C 
API.

llvm-svn: 182407