the register.  While we're at it, make sure it's in the right one.

llvm-svn: 105645

llvm-svn: 105527

In file included from X86InstrInfo.cpp:16:
X86GenInstrInfo.inc:2789: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2790: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2792: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2793: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2808: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2809: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2816: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2817: error: integer constant is too large for 'long' type

llvm-svn: 105524

yet, only assembly encoding support.

llvm-svn: 105521

I don't think this ever resulted in problems on x86, but it
would on ARM.

llvm-svn: 105509

llvm-svn: 105381

llvm-svn: 105377

llvm-svn: 105376

llvm-svn: 105375

instruction defines subregisters.

Any existing subreg indices on the original instruction are preserved or
composed with the new subreg index.

Also substitute multiple operands mentioning the original register by using the
new MachineInstr::substituteRegister() function. This is necessary because there
will soon be <imp-def> operands added to non read-modify-write partial
definitions. This instruction:

  %reg1234:foo = FLAP %reg1234<imp-def>

will reMaterialize(%reg3333, bar) like this:

  %reg3333:bar-foo = FLAP %reg333:bar<imp-def>

Finally, replace the TargetRegisterInfo pointer argument with a reference to
indicate that it cannot be NULL.

llvm-svn: 105358

llvm-svn: 105344

backend.  Add a FIXME noting what can be fixed here.

llvm-svn: 105342

mailing list archives.

llvm-svn: 105341

llvm-svn: 105325

x86 backend currently doesn't know how to handle them.

This doesn't really fix anything because LegalizeTypes doesn't know how to
handle them either.  We do get a better error message, though.

llvm-svn: 105305

llvm-svn: 105303

in X86FastISel. Patch by Jan Sjodin.

llvm-svn: 105290

llvm-svn: 105276

Fix PR7193: if sibling call address can take a register, make sure there are enough registers available by counting inreg arguments.

llvm-svn: 105092

llvm-svn: 105059

llvm-svn: 105014

llvm-svn: 105005

llvm-svn: 105001

getX86RegNum() does not happen.  Patch by Shantonu Sen!

llvm-svn: 104994

llvm-svn: 104890

No functional effect as these nodes are not generated yet.

llvm-svn: 104879

To support this, move IsCalleePop from X86ISelLowering to X86Subtarget.

llvm-svn: 104866

common code between SSE versions.

llvm-svn: 104860

to be matched.

llvm-svn: 104757

This means that our Registers are now ordered R7, R8, R9, R10, R12, ...
Not R1, R10, R11, R12, R2, R3, ...

llvm-svn: 104745

llvm-svn: 104731

llvm-svn: 104713

llvm-svn: 104711

before encoding.

llvm-svn: 104707

A Register with subregisters must also provide SubRegIndices for adressing the
subregisters. TableGen automatically inherits indices for sub-subregisters to
minimize typing.

CompositeIndices may be specified for the weirder cases such as the XMM sub_sd
index that returns the same register, and ARM NEON Q registers where both D
subregs have ssub_0 and ssub_1 sub-subregs.

It is now required that all subregisters are named by an index, and a future
patch will also require inherited subregisters to be named. This is necessary to
allow composite subregister indices to be reduced to a single index.

llvm-svn: 104704

llvm-svn: 104699

llvm-svn: 104697

llvm-svn: 104696

llvm-svn: 104691

This reverts commit 104654.

llvm-svn: 104660