tables.

llvm-svn: 96073

created. This ensures it's updated at all time. It means targets which perform
dynamic stack alignment would know whether it is required and whether frame
pointer register cannot be made available register allocation.
This is a fix for rdar://7625239. Sorry, I can't create a reasonably sized test
case.

llvm-svn: 96069

llvm-svn: 96065

llvm-svn: 96063

We still have the templated X86 JIT emitter, *and* the
almost-copy in X86InstrInfo for getting instruction sizes.

llvm-svn: 96059

fix swapgs to be spelled right.

llvm-svn: 96058

llvm-svn: 96055

encoder and decoder by using new MRM_ forms.

llvm-svn: 96048

rip-relative addresses, and add a testcase.

llvm-svn: 96040

The solution there produces correct code, but is seriously
deficient in several ways.

llvm-svn: 96039

llvm-svn: 96038

addressing.  This isn't complete because I need an MCContext
to generate new MCExprs.

llvm-svn: 96036

Plus add two formats: MiscFrm and ThumbMiscFrm.  Some of the for disassembly
only instructions are changed from Pseudo Format to MiscFrm Format.

llvm-svn: 96032

llvm-svn: 96031

llvm-svn: 96029

llvm-svn: 96028

is pc relative or not, mark call and branches as pcrel.

llvm-svn: 96026

Load / store multiple instructions cannot load / store sp. Sorry, can't come up with a reasonable test case.

llvm-svn: 96023

llvm-svn: 96020

llvm-svn: 96019

stack frame, the prolog/epilog code was using the same
register for the copy of CR and the address of the save slot.  Oops.
This is fixed here for Darwin, sort of, by reserving R2 for this case.
A better way would be to do the store before the decrement of SP,
which is safe on Darwin due to the red zone.

SVR4 probably has the same problem, but I don't know how to fix it;
there is no red zone and R2 is already used for something else.
I'm going to leave it to someone interested in that target.

Better still would be to rewrite the CR-saving code completely;
spilling each CR subregister individually is horrible code.

llvm-svn: 96015

llvm-svn: 96011

llvm-svn: 96010

llvm-svn: 95999

llvm-svn: 95981

This should fix alot of problems we saw so far, e.g. PRs 5851 & 2936

llvm-svn: 95980

This will work better for the disassembler for modeling things
like lfence/monitor/vmcall etc.

llvm-svn: 95960

great solution for the disassembler, we'll go with "plan b".

llvm-svn: 95957

MRRC, MRRc2.  For disassembly only.

llvm-svn: 95955

with "tied memory operands", which is wrong.

llvm-svn: 95950

llvm-svn: 95949

movq	(%ecx,%edx,2), %xmm2
movhps	(%ecx,%eax,2), %xmm2

rather than:

movq     (%eax, %edx, 2), %xmm2		
movq     (%eax, %ebx, 2), %xmm3		
movlhps  %xmm3, %xmm2			

Testcase forthcoming.

llvm-svn: 95948

busted in both encoders.  I'm not bothering to fix it in the
old one at this point.

llvm-svn: 95947

	testb	%al, %al                ## <MCInst #2412 TEST8rr
                                        ##   <MCOperand Reg:2>
                                        ##   <MCOperand Reg:2>>
	jne	LBB1_7                  ## <MCInst #938 JNE_1
                                        ##   <MCOperand Expr:(LBB1_7)>>

llvm-svn: 95935

implemented, llvm-mc --show-inst now uses it to print the
instruction opcode as well as the number.

llvm-svn: 95929

8 or 32-bit immediates, which allows the new encoder to handle
them.

llvm-svn: 95927

the tables to be const.  Teach MCCodeEmitter to handle
the target-indep kinds so that we don't crash on them.

llvm-svn: 95924

llvm-svn: 95920

llvm-svn: 95916

llvm-svn: 95915