Fixes PR11375: Different results for 'clang++ huh.cpp'...

llvm-svn: 144746

llvm-svn: 144743

This will widen 32-bit register vmov instructions to 64-bit when
possible.  The 64-bit vmovd instructions can then be translated to NEON
vorr instructions by the execution dependency fix pass.

The copies are only widened if they are marked as clobbering the whole
D-register.

llvm-svn: 144734

failure during bootstrap with it turned on.

llvm-svn: 144731

%arrayidx135 = getelementptr inbounds [4 x [4 x [4 x [4 x i32]]]]* %M0, i32 0, i64 0
%arrayidx136 = getelementptr inbounds [4 x [4 x [4 x i32]]]* %arrayidx135, i32 0, i64 %idxprom134

Prior to this commit, the GEP instruction that defines %arrayidx136 thought that 
%arrayidx135 was a trivial kill.  The GEP that defines %arrayidx135 doesn't 
generate any code and thus %M0 gets folded into the second GEP.  Thus, we need
to look through GEPs with all zero indices.
rdar://10443319

llvm-svn: 144730

For example,
vld1.f64 {d2-d5}, [r2,:128]!

Should be equivalent to:
vld1.f64 {d2,d3,d4,d5}, [r2,:128]!

It's not documented syntax in the ARM ARM, but it is consistent with what's
accepted for VLDM/VSTM and is unambiguous in meaning, so it's a good thing to
support.

rdar://10451128

llvm-svn: 144727

llvm-svn: 144724

llvm-svn: 144722

llvm-svn: 144721

 

llvm-svn: 144720

llvm-svn: 144719

llvm-svn: 144716

llvm-svn: 144714

llvm-svn: 144713

llvm-svn: 144711

llvm-svn: 144710

llvm-svn: 144709

llvm-svn: 144708

by later instructions.

Only done for DEC64m right now.

Fixes <rdar://problem/6172640>

llvm-svn: 144705

'vld1.f32 d4, [r7]' should be parsed as equivalent to 'vld1.f32 {d4}, [r7]'

rdar://10450488.

llvm-svn: 144701

llvm-svn: 144699

rdar://10435114

llvm-svn: 144698

llvm-svn: 144696

llvm-svn: 144695

rdar://10435076

llvm-svn: 144694

llvm-svn: 144692

Yet more of rdar://10435076.

llvm-svn: 144691

rdar://10449856.

llvm-svn: 144689

Ongoing rdar://10435114.

llvm-svn: 144688

llvm-svn: 144685

rdar://10449724

llvm-svn: 144684

llvm-svn: 144683

When the 3rd operand is not a low-register, and the first two operands are
the same low register, the parser was incorrectly trying to use the 16-bit
instruction encoding.

rdar://10449281

llvm-svn: 144679

llvm-svn: 144675

has a reference to it. Unfortunately, that doesn't work for codegen passes
since we don't get notified of MBB's being deleted (the original BB stays).

Use that fact to our advantage and after printing a function, check if
any of the IL BBs corresponds to a symbol that was not printed. This fixes
pr11202.

llvm-svn: 144674

registers and instructions when ABI is N64.

llvm-svn: 144666

register.

llvm-svn: 144665

llvm-svn: 144664

llvm-svn: 144663

Remove Value::getNameStr. It has been deprecated for a while and provides no additional value over getName().

llvm-svn: 144657