search for: def&use

Displaying 4 results from an estimated 4 matches for "def&use".

2006 Jun 26
0
[LLVMdev] Mapping bytecode to X86
...), you should make sure that the first two operands of the instructions are assigned to the same register, and then you delete one. For example, before RA you might have: vreg1024 = ADDxxx vreg1025, 123 after, you should have: ADDxxx EAX, 123 Where the "EAX" operand is marked as a def&use operand. -Chris -- http://nondot.org/sabre/ http://llvm.org/
2006 Jun 27
2
[LLVMdev] Mapping bytecode to X86
...operands of the instructions are > assigned to the same register, and then you delete one. For example, > before RA you might have: > > vreg1024 = ADDxxx vreg1025, 123 > > after, you should have: > > ADDxxx EAX, 123 > > Where the "EAX" operand is marked as a def&use operand. > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmde...
2006 Jun 26
2
[LLVMdev] Mapping bytecode to X86
...ADD32rr %reg1026, %reg1027 %reg1029 = IMUL32rr %reg1028, %reg1027 MOV32mr %ESP, 1, %NOREG, 4, %reg1029 MOV32mi %ESP, 1, %NOREG, 0, <ga:.str_1> CALLpcrel32 <ga:printf> ADJCALLSTACKUP 8, 0 %reg1030 = MOV32rr %EAX %reg1031 = IMPLICIT_DEF_GR32 %EAX = MOV32rr %reg1031 RET My allocator produces this mapping: FNSTCW16m := MOV8mi := FLDCW16m := MOV32rm EAX := MOV32rm EAX := EAX MOVSX32rm8 ECX := EAX MOVSX32rm8 EAX := EAX ADJCALLSTACKDOW...
2006 Jun 27
0
[LLVMdev] Mapping bytecode to X86
On Mon, 26 Jun 2006, Fernando Magno Quintao Pereira wrote: > Thank you Chris. I will try to implement the TwoAddress pass to run on > machine code. Why it has not been originally implemented to run on > machine code? I'm not sure what you mean. It definitely does run on machine code. > Is there anything that makes it troublesome after RA > has been performed? Do you specifically mean removing the extra operand? One of my eventual goals is to eliminate this behavior of the register allocator. I'd much rather have it leave the inst...