llvm-svn: 223553

All our patterns use MVT::i64, but the ISelLowering nodes were inconsistent in
their choice.

No functional change.

llvm-svn: 223551

llvm-svn: 223549

Somehow made DenseMap probe on forever on 32 bit machines.
This reverts commit r223478.

llvm-svn: 223546

llvm-svn: 223542

llvm-svn: 223536

Reviewed at http://reviews.llvm.org/D6488

llvm-svn: 223532

llvm-svn: 223523

llvm-svn: 223522

llvm-svn: 223521

llvm-svn: 223520

Fix the poor codegen seen in PR21710 ( http://llvm.org/bugs/show_bug.cgi?id=21710 ).
Before we crack 32-byte build vectors into smaller chunks (and then subsequently
glue them back together), we should look for the easy case where we can just load
all elements in a single op.

An example of the codegen change is:

From:

vmovss  16(%rdi), %xmm1
vmovups (%rdi), %xmm0
vinsertps       $16, 20(%rdi), %xmm1, %xmm1
vinsertps       $32, 24(%rdi), %xmm1, %xmm1
vinsertps       $48, 28(%rdi), %xmm1, %xmm1
vinsertf128     $1, %xmm1, %ymm0, %ymm0
retq

To:

vmovups (%rdi), %ymm0
retq

Differential Revision: http://reviews.llvm.org/D6536

llvm-svn: 223518

Patch by Kumar Sukhani!

corresponding compiler-rt patch: http://reviews.llvm.org/D6437
clang patch: http://reviews.llvm.org/D6147

Differential Revision: http://reviews.llvm.org/D6459

llvm-svn: 223516

llvm-svn: 223515

Reviewed at http://reviews.llvm.org/D6488

llvm-svn: 223513

llvm-svn: 223512

Summary:
Follow up to [x32] "Use ebp/esp as frame and stack pointer":
http://reviews.llvm.org/D4617

In that earlier patch, NaCl64 was made to always use rbp.
That's needed for most cases because rbp should hold a full
64-bit address within the NaCl sandbox so that load/stores
off of rbp don't require sandbox adjustment (zeroing the top
32-bits, then filling those by adding r15).

However, llvm.frameaddress returns a pointer and pointers
are 32-bit for NaCl64. In this case, use ebp instead, which
will make the register copy type check. A similar mechanism
may be needed for llvm.eh.return, but is not added in this change.

Test Plan: test/CodeGen/X86/frameaddr.ll

Reviewers: dschuff, nadav

Subscribers: jfb, llvm-commits

Differential Revision: http://reviews.llvm.org/D6514

llvm-svn: 223510

Update of some of the VSX test cases for Power to check fast-isel codegen as well as the regular codegen.

http://reviews.llvm.org/D6357

llvm-svn: 223509

This patch adds VSX floating point loads and stores to fastisel.

Along with the change to tablegen (D6220), VSX instructions are now fully supported in fastisel.

http://reviews.llvm.org/D6274

llvm-svn: 223507

llvm-svn: 223506

SSE2/AVX non-constant packed shift instructions only use the lower 64-bit of
the shift count. 

This patch teaches function 'getTargetVShiftNode' how to deal with shifts
where the shift count node is of type MVT::i64.

Before this patch, function 'getTargetVShiftNode' only knew how to deal with
shift count nodes of type MVT::i32. This forced the backend to wrongly
truncate the shift count to MVT::i32, and then zero-extend it back to MVT::i64.

llvm-svn: 223505

llvm-svn: 223504

llvm-svn: 223503

llvm-svn: 223502

When a loop gets bundled up, its outgoing edges are quite large, and can
just barely overflow 64-bits.  If one successor has multiple incoming
edges -- and that successor is getting all the incoming mass --
combining just its edges can overflow.  Handle that by saturating rather
than asserting.

This fixes PR21622.

llvm-svn: 223500

llvm-svn: 223494

llvm-svn: 223493

llvm-svn: 223492

llvm-svn: 223491

llvm-svn: 223488

llvm-svn: 223487

llvm-svn: 223486

llvm-svn: 223485

[Hexagon] Marking several instructions as isCodeGenOnly=0 and adding direct disassembly tests for many instructions.

llvm-svn: 223482

It is only build if LLVM_BINUTILS_INCDIR is explicitly given, so there is
no point in having extra restrictions.

llvm-svn: 223481

Required some APInt massaging to get proper empty/tombstone values. Apart
from making the code a bit simpler this also reduces the bucket size of
the ConstantInt map from 32 to 24 bytes.

llvm-svn: 223478

No functional changes. Got myself bitten in r223113 when adding support for
modified immediate syntax (regressions reported by joerg@britannica.bec.de,
fixes in r223366 and r223381). Our assembler tests did not cover serveral
different syntax variants. This patch expands the test coverage to check for
the following cases:

1. Modified immediate operands may be expressed with expressions, as in #(4 * 2)
instead of #8.

2. Modified immediate operands may be _optionally_ prefixed by a '#' symbol or a
'$' symbol.

3. Certain instructions (e.g. ADD) support single input register variants;
[ADD r0, #mod_imm] is same as [ADD r0, r0, #mod_imm].

4. Certain instructions have aliases which convert plain immediates to modified
immediates. For an example, [ADD r0, -10] is not valid because -10 (in two's
complement) cannot be encoded as a modified immediate, but ARMInstrInfo.td
defines an alias which can transform this into a [SUB r0, 10].

llvm-svn: 223475

llvm-svn: 223474

Phabricator revision: http://reviews.llvm.org/D6543

llvm-svn: 223473

Phabricator revision: http://reviews.llvm.org/D6535

llvm-svn: 223472