vldr.64 d1, [r0, #-32]

The problem was with how the addressing mode 5 encodes the offsets. This change
makes sure that the way offsets are handled in addressing mode 5 is consistent
throughout the MC code. It involves re-refactoring the "getAddrModeImmOpValue"
method into an "Imm12" and "addressing mode 5" version. But not to worry! The
majority of the duplicated code has been unified.

llvm-svn: 118144

parts. Represent the operation mode as an optional operand instead.
rdar://8614429

llvm-svn: 118137

with immediates up to 16-bits in size. The same logic is applied to other LDR
encodings, e.g. VLDR, but which use a different immediate bit width (8-bits in
VLDR's case). Removing the "12" allows it to be more generic.

llvm-svn: 118094

llvm-svn: 117971

llvm-svn: 117969

llvm-svn: 117956

*_Encode classes. These instructions are the only ones which use those classes,
so a subclass isn't necessary.

llvm-svn: 117906

got a dulicated line).

llvm-svn: 117860

llvm-svn: 117859

Instead of silently ignoring these instructions, emit a hard error and
force the target author to either refactor the target or mark the 
instruction 'isCodeGenOnly'.

Mark a few instructions in ARM and MBlaze as isCodeGenOnly the are 
doing this.

llvm-svn: 117858

llvm-svn: 117787

extension register.

llvm-svn: 116970

registers.

llvm-svn: 116961

llvm-svn: 116625

here. The f32 in FCONSTS is handled as a double instead of a float in the
code. So the encoding of the immediate into the instruction isn't exactly in
line with the documentation in that regard. But given that we know it's handled
as a double, it doesn't cause any harm.

llvm-svn: 116471

llvm-svn: 116466

- Add missing patterns for some multiply add/subtract instructions.
- Add encodings for VMRS and VMSR.

llvm-svn: 116464

llvm-svn: 116431

just yet.

llvm-svn: 116386

llvm-svn: 116385

llvm-svn: 116383

llvm-svn: 116379

llvm-svn: 116375

llvm-svn: 116370

to add 10+ lines to every instruction.

It may turn out that we can move this base class into it's parent class.

llvm-svn: 116362

Fear not! I'm going to try a refactoring right now. :)

llvm-svn: 116359

llvm-svn: 116348

llvm-svn: 116338

llvm-svn: 115898

llvm-svn: 114931

llvm-svn: 113322

all the other LDM/STM instructions.  This fixes asm printer crashes when
compiling with -O0.  I've changed one of the NEON tests (vst3.ll) to run
with -O0 to check this in the future.

Prior to this change VLDM/VSTM used addressing mode #5, but not really.
The offset field was used to hold a count of the number of registers being
loaded or stored, and the AM5 opcode field was expanded to specify the IA
or DB mode, instead of the standard ADD/SUB specifier.  Much of the backend
was not aware of these special cases.  The crashes occured when rewriting
a frameindex caused the AM5 offset field to be changed so that it did not
have a valid submode.  I don't know exactly what changed to expose this now.
Maybe we've never done much with -O0 and NEON.  Regardless, there's no longer
any reason to keep a count of the VLDM/VSTM registers, so we can use
addressing mode #4 and clean things up in a lot of places.

llvm-svn: 112322

for some reason they have a very odd MCInst form where the operands overlap, but
I haven't dug in to find out why yet.

llvm-svn: 110781

Add support for using the FPSCR in conjunction with the vcvtr instruction, for controlling fp to int rounding.
Add support for the FLT_ROUNDS_ node now that the FPSCR is exposed.

llvm-svn: 110152

llvm-svn: 105350

Mark pattern-less mayLoad / mayStore instructions neverHasSideEffects. These do not have other un-modeled side effects.

llvm-svn: 104111

llvm-svn: 103683

Define new itin classes for ARM <-> VFP reg moves to distinguish from NEON ops. Define proper scheduling itinerary for them on A9. A8 TRM does not specify latency for them at all :(

llvm-svn: 100650

llvm-svn: 100649

llvm-svn: 100647