and %rcr_, leaving just %cr_ which is what people expect.
Updated the disassembler to support this unified register set.
Added a testcase to verify that the registers continue to be
decoded correctly.

llvm-svn: 103196

doesn't have to guess.

llvm-svn: 103194

Re-apply 103156 and 103157. 103156 didn't break anything. 10315 exposed a coalescer bug that's fixed by 103170.

llvm-svn: 103172

llvm-svn: 103164

when building llvm with clang

llvm-svn: 103084

llvm-svn: 103073

llvm-svn: 103071

and diagnostic groups.  This allows the compiler to group 
diagnostics together (e.g. "Logic Warning", 
"Format String Warning", etc) like the static analyzer does.  
This is not exposed through anything in the compiler yet.

llvm-svn: 103050

name (for example, to allow targets to interpose the actual MatchInstruction
function).

llvm-svn: 102987

sub-register indices and outputs a single super register which is formed from
a consecutive sequence of registers.

This is used as register allocation / coalescing aid and it is useful to
represent instructions that output register pairs / quads. For example,
v1024, v1025 = vload <address>
where v1024 and v1025 forms a register pair.

This really should be modelled as
v1024<3>, v1025<4> = vload <address>
but it would violate SSA property before register allocation is done.

Currently we use insert_subreg to form the super register:
v1026 = implicit_def
v1027 - insert_subreg v1026, v1024, 3
v1028 = insert_subreg v1027, v1025, 4
...
      = use v1024
      = use v1028

But this adds pseudo live interval overlap between v1024 and v1025.

We can now modeled it as
v1024, v1025 = vload <address>
v1026 = REG_SEQUENCE v1024, 3, v1025, 4
...
      = use v1024
      = use v1026

After coalescing, it will be
v1026<3>, v1025<4> = vload <address>
...
      = use v1026<3>
      = use v1026

llvm-svn: 102815

memory operands rather than immediate operands.

llvm-svn: 102217

as their generic counterparts t2ADDri12/t2SUBri12 should suffice.

llvm-svn: 101929

llvm-svn: 101881

llvm-svn: 101880

FU per CPU arch to 32 per intinerary allowing precise modelling of quite
complex pipelines in the future.

llvm-svn: 101754

llvm-svn: 101376

llvm-svn: 101241

code.  It used to #include the enhanced disassembly
information for the targets it supported straight
out of lib/Target/{X86,ARM,...} but now it uses a
new interface provided by MCDisassembler, and (so
far) implemented by X86 and ARM.

Also removed hacky #define-controlled initialization
of targets in edis.  If clients only want edis to
initialize a limited set of targets, they can set
--enable-targets on the configure command line.

llvm-svn: 101179

We are bound to fail!  For proper disassembly, the well-known encoding bits
of the instruction must be fully specified.

This also removes pseudo instructions from considerations of disassembly,
which is a better design and less fragile than the name matchings.

llvm-svn: 100899

such that the non-VFP versions have no implicit defs of VFP registers.
If any callee-saved VFP registers are marked as having been defined, the
prologue/epilogue code will try to save and restore them.
Radar 7770432.

llvm-svn: 100892

encounters decoding conflicts, instead of wrapping it inside the DEBUG() macro. 

llvm-svn: 100886

to avoid memcpy() call is no longer necessary.

llvm-svn: 100811

llvm-svn: 100767

llvm-svn: 100754

I also added a rule to the ARM target's Makefile to
build the ARM-specific instruction information table
for the enhanced disassembler.

I will add the test harness for all this stuff in
a separate commit.

llvm-svn: 100735

llvm-svn: 100709

argument that had to be between 0 and 7 to have any value,
firing an assert later in the AsmPrinter.  Now, the
disassembler rejects instructions with out-of-range values
for that immediate.

llvm-svn: 100694

llvm-svn: 100691

ARMDecoderEmitter.cpp, with FIXME comment.

llvm-svn: 100690

llvm-svn: 100645

When a target instruction wants to set target-specific flags, it should simply
set bits in the TSFlags bit vector defined in the Instruction TableGen class.

This works well because TableGen resolves member references late:

class I : Instruction {
  AddrMode AM = AddrModeNone;
  let TSFlags{3-0} = AM.Value;
}

let AM = AddrMode4 in
def ADD : I;

TSFlags gets the expected bits from AddrMode4 in this example.

llvm-svn: 100384

member of AsmPrinter.  Instead, pass it in explicitly.

llvm-svn: 100306

llvm-svn: 100268

llvm-svn: 100267

is expected.

llvm-svn: 100247

llvm-svn: 100244

(Fix build failure)

llvm-svn: 100243

backend (ARMDecoderEmitter) which emits the decoder functions for ARM and Thumb,
and the disassembler core which invokes the decoder function and builds up the
MCInst based on the decoded Opcode.

Reviewed by Chris Latter and Bob Wilson.

llvm-svn: 100233

doesn't need to be stable because the patterns are fully ordered.

Add a first level sort predicate that orders patterns in this
order:  1) scalar integer operations 2) scalar floating point 
3) vector int 4) vector float.  This is a trivial sort on their
top level pattern type so it is nice and transitive.  The
benefit of doing this is that simple integer operations are
much more common than insane vector things and isel was trying
to match the big complex vector patterns before the simple
ones because the complexity of the vector operations was much
higher.  Since they can't both match, it is best (for compile
time) to try the simple integer ones first.

This cuts down the # failed match attempts on real code by
quite a bit, for example, this reduces backtracks on crafty
(as a random example) from 228285 -> 188369.

llvm-svn: 99797

llvm-svn: 99796