llvm-svn: 127807

llvm-svn: 127788

llvm-svn: 127786

rather than an int. Thankfully, this only causes LLVM to miss optimizations, not
generate incorrect code.

This just fixes the zext at the return. We still insert an i32 ZextAssert when
reading a function's arguments, but it is followed by a truncate and another i8
ZextAssert so it is not optimized.

llvm-svn: 127766

llvm-svn: 127761

can event.

llvm-svn: 127741

1. The ARM Darwin *r9 call instructions were pseudo-ized recently.
   Modify the ARMDisassemblerCore.cpp file to accomodate the change.

2. The disassembler was unnecessarily adding 8 to the sign-extended imm24:

   imm32 = SignExtend(imm24:'00', 32); // A8.6.23 BL, BLX (immediate)
                                       // Encoding A1

   It has no business doing such.  Removed the offending logic.

Add test cases to arm-tests.txt.

llvm-svn: 127707

accept. If a value in the mask is out of range, it uses the value 0, for VTBL,
or leaves the value unchanged, for VTBX.

llvm-svn: 127700

llvm-svn: 127694

llvm-svn: 127683

llvm-svn: 127681

llvm-svn: 127680

llvm-svn: 127678

- Remove PTX 1.4 code generation
- Change type of intrinsics to .v4.i32 instead of .v4.i16
- Add and/or/xor integer instructions

llvm-svn: 127677

when building with assertions disabled.

llvm-svn: 127675

in the instruction tables and fixed a few bugs that
were causing decode conflicts.  Rudimentary tests
are coming up in the next patch.

llvm-svn: 127646

instruction set.  This code adds support for the VEX prefix
and for the YMM registers accessible on AVX-enabled
architectures.  Instruction table support that enables AVX
instructions for the disassembler is in an upcoming patch.

llvm-svn: 127644

register operand was erroneously added.  Remove an incorrect assert which triggers the bug.

rdar://problem/9131529

llvm-svn: 127642

Also more cleanly separate the ARM vs. Thumb functionality. Previously, the
encoding would be incorrect for some Thumb instructions (the indirect calls).

llvm-svn: 127637

can. As Nate pointed out, VTBL isn't super performant, but it *has* to be better
than this:

_shuf:
@ BB#0:       @ %entry
  push        {r4, r7, lr}
  add         r7, sp, #4
  sub         sp, #12
  mov         r4, sp
  bic         r4, r4, #7
  mov         sp, r4
  mov         r2, sp
  vmov        d16, r0, r1
  orr         r0, r2, #6
  orr         r3, r2, #7
  vst1.8      {d16[0]}, [r3]
  vst1.8      {d16[5]}, [r0]
  subs        r4, r7, #4
  orr         r0, r2, #5
  vst1.8      {d16[4]}, [r0]
  orr         r0, r2, #4
  vst1.8      {d16[4]}, [r0]
  orr         r0, r2, #3
  vst1.8      {d16[0]}, [r0]
  orr         r0, r2, #2
  vst1.8      {d16[2]}, [r0]
  orr         r0, r2, #1
  vst1.8      {d16[1]}, [r0]
  vst1.8      {d16[3]}, [r2]
  vldr.64     d16, [sp]
  vmov        r0, r1, d16
  mov         sp, r4
  pop         {r4, r7, pc}

The "illegal" testcase in vext.ll is no longer illegal.
<rdar://problem/9078775>

llvm-svn: 127630

llvm-svn: 127601

llvm-svn: 127595

- Emit all arrays as type .b8 and proper sizes in bytes to conform
  to the output of nvcc

llvm-svn: 127584

llvm-svn: 127578

llvm-svn: 127577

llvm-svn: 127569

Go ahead and add them on when we might want to use them and let
later passes remove them.

Fixes rdar://9118569

llvm-svn: 127518

llvm-svn: 127516

actual instruction as the non-Darwin defs, but have different call-clobber
semantics and so need separate patterns. They don't need to duplicate the
encoding information, however.

llvm-svn: 127515

llvm-svn: 127511

llvm-svn: 127510

llvm-svn: 127509

llvm-svn: 127506

llvm-svn: 127505

effect that we get proper instruction printing using the "pop" mnemonic for it.

llvm-svn: 127502

as for VDUP32d and VDUP32q, respectively.

llvm-svn: 127489

and VDUPLN32d, respectively.

llvm-svn: 127486

as for VREV64d32 and VREV64q32, respectively.

llvm-svn: 127485

llvm-svn: 127483

llvm-svn: 127482