Displaying 4 results from an estimated 4 matches for "mov8r0".
Did you mean:
mov8rr
2010 May 18
2
[LLVMdev] Fast register allocation
...reg1028<def> = MOV32rm <fi#2>, 1, %reg0, 0, %reg0
%reg1029<def> = MOV32rm <fi#2>, 1, %reg0, 4, %reg0
ADJCALLSTACKDOWN64 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP<imp-use>
%reg1030<def> = LEA64r %RIP, 1, %reg0, <ga:@.str>
%reg1031<def> = MOV8r0 %EFLAGS<imp-def,dead>
%RDI<def> = MOV64rr %reg1030
%ESI<def> = MOV32rr %reg1028
%EDX<def> = MOV32rr %reg1029
%AL<def> = MOV8rr %reg1031
CALL64pcrel32 <ga:@printf>, %RDI, %ESI, %EDX, %AL, %RAX<imp-def>, %RDX<imp-def>, %RSI<imp-def>, %RDI<...
2007 Jun 26
3
[LLVMdev] Live Intervals Question
...<fi#0> 1 %mreg(0) 0
4 MOV8mi <fi#0>, 1, %NOREG, 1, 2
MOV8mi <fi#0> 1 %mreg(0) 1 2
8 FLDCW16m <fi#0>, 1, %NOREG, 0
FLDCW16m <fi#0> 1 %mreg(0) 0
12 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %ESP<imp-use>
ADJCALLSTACKDOWN 0 %mreg(25)<d> %mreg(25)
16 %reg1024 = MOV8r0
MOV8r0 %reg1024<d>
20 %reg1025 = LEA64r %NOREG, 1, %NOREG,
<ga:initialized$$$CFE_id_cc092431_main>
LEA64r %reg1025<d> %mreg(0) 1 %mreg(0) <ga:initialized$$$CFE_id_cc092431_main>
24 %RDI = MOV64rr %reg1025<kill>
MOV64rr %mreg(78)<d> %reg1025
28 %AL<dead> =...
2008 Apr 16
0
[LLVMdev] Being able to know the jitted code-size before emitting
...izeConstPoolAddress(dword);
> + else if (MO.isJumpTableIndex())
> + FinalSize += sizeJumpTableAddress(dword);
> + }
> + }
> + break;
> + }
> +
> + case X86II::MRMInitReg:
> + ++FinalSize;
> + // Duplicate register, used by things like MOV8r0 (aka xor
> reg,reg).
> + FinalSize += sizeRegModRMByte();
> + ++CurOp;
> + break;
> + }
> +
> + if (!Desc->isVariadic() && CurOp != NumOps) {
> + cerr << "Cannot encode: ";
"Cannot determine size"?
>
> + MI.dump...
2008 Apr 15
4
[LLVMdev] Being able to know the jitted code-size before emitting
OK, here's a new patch that adds the infrastructure and the
implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize.
Both functions are virtual functions defined in TargetInstrInfo.h.
For X86, I moved some commodity functions from X86CodeEmitter to
X86InstrInfo.
What do you think?
Nicolas
Evan Cheng wrote:
>
> I think both of these belong to TargetInstrInfo. And