Part of rdar://9643582

llvm-svn: 134095

The tSpill and tRestore instructions are just copies of the tSTRspi and
tLDRspi instructions, respectively. Just use those directly instead.

llvm-svn: 134092

llvm-svn: 134049

llvm-svn: 134030

llvm-svn: 134027

llvm-svn: 134024

sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.

llvm-svn: 134021

llvm-svn: 134014

When the destination operand is the same as the first source register
operand for arithmetic instructions, the destination operand may be omitted.

For example, the following two instructions are equivalent:
and r1, #ff
and r1, r1, #ff

rdar://9672867

llvm-svn: 133973

Correctly parse the forms of the Thumb mov-immediate instruction:
  1. 8-bit immediate 0-255.
  2. 12-bit shifted-immediate.

The 16-bit immediate "movw" form is also legal with just a "mov" mnemonic,
but is not yet supported. More parser logic necessary there due to fixups.

llvm-svn: 133966

Thumb2 MOV mnemonic can accept both cc_out and predication. We don't (yet)
encode the instruction properly, but this gets the parsing part.

llvm-svn: 133945

llvm-svn: 133944

llvm-svn: 133939

llvm-svn: 133938

llvm-svn: 133936

Add aliases for the vpush/vpop mnemonics to the VFP load/store multiple
writeback instructions w/ SP as the base pointer.

rdar://9683231

llvm-svn: 133932

When the destination operand is the same as the first source register
operand for arithmetic instructions, the destination operand may be omitted.

For example, the following two instructions are equivalent:
  sub r2, r2, #6
  sub r2, #6

rdar://9682597

llvm-svn: 133925

into XXXGenRegisterInfo.inc.

llvm-svn: 133922

Move the target-specific RecordRelocation logic out of the generic MC
MachObjectWriter and into the target-specific object writers. This allows
nuking quite a bit of target knowledge from the supposedly target-independent
bits in lib/MC.

llvm-svn: 133844

The fixup value comes in as the whole 32-bit value, so for the lo16 fixup,
the upper bits need to be masked off. Previously we assumed the masking had
already been done and asserted.

rdar://9635991

llvm-svn: 133818

instructions can be used to match combinations of multiply/divide and VCVT 
(between floating-point and integer, Advanced SIMD).  Basically the VCVT 
immediate operand that specifies the number of fraction bits corresponds to a 
floating-point multiply or divide by the corresponding power of 2.

For example, VCVT (floating-point to fixed-point, Advanced SIMD) can replace a 
combination of VMUL and VCVT (floating-point to integer) as follows:

Example (assume d17 = <float 8.000000e+00, float 8.000000e+00>):
  vmul.f32        d16, d17, d16
  vcvt.s32.f32    d16, d16
becomes:
  vcvt.s32.f32    d16, d16, #3

Similarly, VCVT (fixed-point to floating-point, Advanced SIMD) can replace a 
combinations of VCVT (integer to floating-point) and VDIV as follows:

Example (assume d17 = <float 8.000000e+00, float 8.000000e+00>):
  vcvt.f32.s32    d16, d16
  vdiv.f32        d16, d17, d16
becomes:
  vcvt.f32.s32    d16, d16, #3

llvm-svn: 133813

target machine from those that are only needed by codegen. The goal is to
sink the essential target description into MC layer so we can start building
MC based tools without needing to link in the entire codegen.

First step is to refactor TargetRegisterInfo. This patch added a base class
MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to
separate register description from the rest of the stuff.

llvm-svn: 133782

llvm-svn: 133738

llvm-svn: 133640

Just tidy up a bit. No functional change.

llvm-svn: 133638

Noticed on inspection.

llvm-svn: 133553

llvm-svn: 133533

1. (((x) & 0xFF00) >> 8) | (((x) & 0x00FF) << 8)
   => (bswap x) >> 16
2. ((x&0xff)<<8)|((x&0xff00)>>8)|((x&0xff000000)>>8)|((x&0x00ff0000)<<8))
   => (rotl (bswap x) 16)

This allows us to eliminate most of the def : Pat patterns for ARM rev16
revsh instructions. It catches many more cases for ARM and x86.

rdar://9609108

llvm-svn: 133503

llvm-svn: 133347

This slightly changes the GPR allocation order on Darwin where R9 is not
a callee-saved register:

Before: %R0 %R1 %R2 %R3 %R12 %R9 %LR %R4 %R5 %R6 %R8 %R10 %R11
After:  %R0 %R1 %R2 %R3 %R9 %R12 %LR %R4 %R5 %R6 %R8 %R10 %R11
llvm-svn: 133326

llvm-svn: 133321

Add an alternative rev16 pattern. We should figure out a better way to handle these complex rev patterns. rdar://9609108

llvm-svn: 133289

tail call pseudoinstruction. This fixes <rdar://problem/9624333>.

llvm-svn: 133227

Patch by Richard Smith!

llvm-svn: 133220

Also switch the return type to ArrayRef<unsigned> which works out nicely
for ARM's implementation of this function because of the clever ArrayRef
constructors.

The name change indicates that the returned allocation order may contain
reserved registers as has been the case for a while.

llvm-svn: 133216

Change the REG_SEQUENCE SDNode to take an explict register class ID as its first operand.  This operand is lowered away by the time we reach MachineInstrs, so the actual register-allocation handling of them doesn't need to change.
This is intended to support using REG_SEQUENCE SDNode's with type MVT::untyped, and is part of the long road to eliminating some of the hacks we currently use to support register pairs and other strange constraints, particularly on ARM NEON.

llvm-svn: 133178

llvm-svn: 133175

accumulator forwarding.  Specifically (from SVN log entry):

Distribute (A + B) * C to (A * C) + (B * C) to make use of NEON multiplier
accumulator forwarding:
vadd d3, d0, d1
vmul d3, d3, d2
=>
vmul d3, d0, d2
vmla d3, d1, d2

Make sure it catches cases where operand 1 is add/fadd/sub/fsub, which was
intended in the original revision.

llvm-svn: 133127

This simplifies many of the target description files since it is common
for register classes to be related or contain sequences of numbered
registers.

I have verified that this doesn't change the files generated by TableGen
for ARM and X86. It alters the allocation order of MBlaze GPR and Mips
FGR32 registers, but I believe the change is benign.

llvm-svn: 133105

llvm-svn: 133064