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

Preliminary testing shows significant performance wins by not using these
instructions.

llvm-svn: 99436

--- Reverse-merging r98679 into 'lib/Target/ARM/ARMInstrVFP.td':
U    lib/Target/ARM/ARMInstrVFP.td

llvm-svn: 99049

--- Reverse-merging r98889 into '.':
U    lib/Target/ARM/ARMInstrNEON.td
U    lib/Target/ARM/ARMISelLowering.h
U    lib/Target/ARM/ARMInstrInfo.td
U    lib/Target/ARM/ARMInstrVFP.td
U    lib/Target/ARM/ARMISelLowering.cpp
U    lib/Target/ARM/ARMInstrFormats.td

llvm-svn: 99010

llvm-svn: 98889

llvm-svn: 98888

This is for the disassembly work.

There are cases where this is not possible, for example, A8.6.53 LDM Encoding T1.
In such case, we'll use an adhoc approach to deduce the Opcode programmatically.

llvm-svn: 98679

llvm-svn: 98648

llvm-svn: 98502

base register updating load/store-multiple instructions.

llvm-svn: 98427

writebacks to the address register.  This gets rid of the hack that the
first register on the list was the magic writeback register operand.  There
was an implicit constraint that if that operand was not reg0 it had to match
the base register operand.  The post-RA scheduler's antidependency breaker
did not understand that constraint and sometimes changed one without the
other.  This also fixes Radar 7495976 and should help the verifier work
better for ARM code.

There are now new ld/st instructions explicit writeback operands and explicit
constraints that tie those registers together.

llvm-svn: 98409

example, this:

(set DPR:$dst, (fsub (fneg (fmul DPR:$a, DPR:$b)), DPR:$dstin))

is ambiguous because DPR contains both f64 and v2f32.  tblgen
currently accidentally picks f64 because it's first in the 
regclass.

llvm-svn: 97955

llvm-svn: 97348

A8.6.297

llvm-svn: 95885

A8.6.335 & A8.6.336

llvm-svn: 95703