llvm-svn: 117737

llvm-svn: 117718

the ARMExpandPseudos pass rather than during the asm lowering.

llvm-svn: 117714

failure for llvm-gcc on arm fast isel.

llvm-svn: 117710

handle it in the asm lowering.

llvm-svn: 117707

llvm-svn: 117703

llvm-svn: 117702

llvm-svn: 117695

llvm-svn: 117687

operand and one of them has a single use that is a live out copy, favor the
one that is live out. Otherwise it will be difficult to eliminate the copy
if the instruction is a loop induction variable update. e.g.

BB:
sub r1, r3, #1
str r0, [r2, r3]
mov r3, r1
cmp
bne BB

=>

BB:
str r0, [r2, r3]
sub r3, r3, #1
cmp
bne BB

This fixed the recent 256.bzip2 regression.

llvm-svn: 117675

- Compute CopyToReg use operand latency correctly.

llvm-svn: 117674

llvm-svn: 117672

Inline asm multiple alternative constraints development phase 2 - improved basic logic, added initial platform support.

llvm-svn: 117667

llvm-svn: 117663

llvm-svn: 117660

llvm-svn: 117651

llvm-svn: 117648

fully enumerated.

llvm-svn: 117647

vldr.64 to work.  I have no idea if this is fully right, but 
it is in the right direction.

llvm-svn: 117626

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: 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

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: 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