rdar://10602276

llvm-svn: 146895

direct-object emitter should emit the appropriate shift instruction depending
on the shift amount.

llvm-svn: 146893

llvm-svn: 146892

llvm-svn: 146889

This change reduces the number of instructions generated.

For example, 
(load (add (sub $n0, $n1), (MipsLo got(s))))

results in the following sequence of instructions:
1. sub $n2, $n0, $n1
2. lw got(s)($n2)

Previously, three instructions were needed.
1. sub $n2, $n0, $n1
2. addiu $n3, $n2, got(s)
3. lw 0($n3)

llvm-svn: 146888

llvm-svn: 146887

llvm-svn: 146885

There's more variation that we need to handle. Error checking will need
to be on operand predicates.

llvm-svn: 146884

llvm-svn: 146882

Add the new TableGen register class synthesizer feature to the release
notes.

llvm-svn: 146875

Use information computed while inferring new register classes to emit
accurate, table-driven implementations of getMatchingSuperRegClass().

Delete the old manual, error-prone implementations in the targets.

llvm-svn: 146873

llvm-svn: 146852

Some compilers were complaining about passing StringRef to it.

llvm-svn: 146850

llvm-svn: 146846

llvm-svn: 146833

llvm-svn: 146831

llvm-svn: 146805

asm parsing and testcase.

llvm-svn: 146801

llvm-svn: 146800

I don't think this affects anything but verbose assembly.

llvm-svn: 146787

The bad sorting caused a misaligned basic block when building 176.vpr in
ARM mode.

<rdar://problem/10594653>

llvm-svn: 146767

This adjustment is already included in the block offsets computed by
BasicBlockInfo, and adjusting again here can cause the pass to loop.

When CreateNewWater splits a basic block, OffsetIsInRange would reject
the new CPE on the next pass because of the too conservative alignment
adjustment. This caused the block to be split again, and so on.

llvm-svn: 146751

Reenable the tests.

llvm-svn: 146750

The command line option should be removed, but not until the feature has
gotten a lot of testing. The ARMConstantIslandPass tends to have subtle
bugs that only show up after a while.

llvm-svn: 146739

Don't try to match 'unpackl/h v, v' for 32xi8 and 16xi16 when only AVX1 is supported. Fix 'unpackh v, v' for 256-bit types to understand 128-bit lanes.

llvm-svn: 146726

llvm-svn: 146724

llvm-svn: 146714

llvm-svn: 146710

Make sure we correctly note the existence of an i8 immediate for vblendvps and friends, so we compute fixups correctly.  PR11586.

llvm-svn: 146709

llvm-svn: 146702

Make check a bit more strict so we don't call ARM_AM::getFP32Imm with a value that isn't a 32-bit value.  (This is just to be safe; I don't think this actually causes any issues in practice.)

llvm-svn: 146700

llvm-svn: 146699

llvm-svn: 146692

llvm-svn: 146691

The code size increase is tiny (< 0.05%) because so little code uses
16-byte constant pool entries.

llvm-svn: 146690

Patch by Elena Demikhovsky <elena.demikhovsky@intel.com>!

llvm-svn: 146689

llvm-svn: 146686

llvm-svn: 146685

Patch by Elena Demikhovsky <elena.demikhovsky@intel.com>!

llvm-svn: 146684

Fix VSELECT operand order. Was previously backwards, causing bogus vector shift results - <rdar://problem/10559581>.

llvm-svn: 146671