t.s:1:14: error: invalid operand for instruction
vldr.64	d17, [r0]   
       	     ^

instead of:

t.s:1:1: error: unrecognized instruction
vldr.64	d17, [r0]   
^

llvm-svn: 117611

the opcode string in the inst dump, e.g.:
	vmov	r2, r3, d17             @ encoding: [0x31,0x2b,0x53,0xec]
                                        @ <MCInst #989 VMOVRRD
                                        @  <MCOperand Reg:68>
                                        @  <MCOperand Reg:69>
                                        @  <MCOperand Reg:19>
                                        @  <MCOperand Imm:14>
                                        @  <MCOperand Reg:0>>

The "VMOVRRD" is new.

llvm-svn: 117609

llvm-svn: 117605

llvm-svn: 117603

llvm-svn: 117572

llvm-svn: 117571

llvm-svn: 117560

llvm-svn: 117559

llvm-svn: 117531

llvm-svn: 117520

- For now, loads of [r, r] addressing mode is the same as the
  [r, r lsl/lsr/asr #] variants. ARMBaseInstrInfo::getOperandLatency() should
  identify the former case and reduce the output latency by 1.
- Also identify [r, r << 2] case. This special form of shifter addressing mode
  is "free".

llvm-svn: 117519

Bruno, please review, but I'm pretty sure this is right.
Patch by Alex Mac!

llvm-svn: 117514

llvm-svn: 117513

llvm-svn: 117512

llvm-svn: 117511

complex load / store addressing mode) when they have higher cost and
when they have more than one use.

llvm-svn: 117509

the LDR instructions have. This makes the literal/register forms of the
instructions explicit and allows us to assign scheduling itineraries
appropriately. rdar://8477752

llvm-svn: 117505

for specifying fractional bits for fixed point conversions.

llvm-svn: 117501

llvm-svn: 117496

llvm-svn: 117495

llvm-svn: 117485

llvm-svn: 117483

elements than the result vector type.  So, when an instruction like:

%8 = shufflevector <2 x float> %4, <2 x float> %7, <4 x i32> <i32 1, i32 0, i32 3, i32 2>

is translated to a DAG, each operand is changed to a concat_vectors node that appends 2 undef elements.  That is:

shuffle [a,b], [c,d] is changed to:
shuffle [a,b,u,u], [c,d,u,u]

That's probably the right thing for x86 but for NEON, we'd much rather have:

shuffle [a,b,c,d], undef

Teach the DAG combiner how to do that transformation for ARM.  Radar 8597007.

llvm-svn: 117482

llvm-svn: 117478

llvm-svn: 117475

llvm-svn: 117474

operands in the TableGen'erated bits, so we don't need to do the additional
magic explicitly.

llvm-svn: 117461

llvm-svn: 117459

llvm-svn: 117458

encoding tricks. Handle the 'imm doesn't fit in the insn' case.

llvm-svn: 117454

(still to add ud2b).

llvm-svn: 117435

the wait prefix).

llvm-svn: 117434

sense, when the instruction takes the 16-bit ax register or m16 memory
location.  These changes to llvm-mc matches what the darwin assembler
allows for these instructions.  Done differently than in r117031 that
caused a valgrind error which was later reverted.

llvm-svn: 117433

integer values), not with the addrmode2 encoding.

llvm-svn: 117429

will accept versions that the darwin assembler allows.  Forms ending in "pi" and
forms without all the operands.

llvm-svn: 117427

doesn't need the additional addrmode2 register operand. Missed it the first
time around.

llvm-svn: 117421

llvm-svn: 117420

rdar://8477752.

llvm-svn: 117419

llvm-svn: 117418

memory, so a MachineMemOperand is useful (not propagated
into the MachineInstr yet).  No functional change except
for dump output.

llvm-svn: 117413