search for: reg1030

I have two questions regarding MachineMemOperands and dependence information. Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. (before optimization) %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14, pred:%reg0; mem:LD4[%uglygep2021] (after optimization) %reg1054<def>, %reg1033<def> = LDRD %reg1030, %reg0, 264, pred:14, pred:%reg0 Are there any reasons they need to be r...

...gt; I have two questions regarding MachineMemOperands and dependence information. > > Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. > > (before optimization) > %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] > %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14, pred:%reg0; mem:LD4[%uglygep2021] > > (after optimization) > %reg1054<def>, %reg1033<def> = LDRD %reg1030, %reg0, 264, pred:14, pred:%reg0 > > Are there...

...output from LLVM shows this: ********** REWRITING TWO-ADDR INSTRS ********** ********** Function: sext %reg1028<def> = sextb_r %reg1025<kill> prepend: %reg1028<def> = mov_rr %reg1025<kill> rewrite to: %reg1028<def> = sextb_r %reg1028 ... %reg1030<def> = sextw_r %reg1026<kill> prepend: %reg1030<def> = mov_rr %reg1026<kill> rewrite to: %reg1030<def> = sextw_r %reg1030 Because sextb_r and sextw_r have destination tied to source operands, TwoAddressInstructionPass thinks it needs a copy. How...

...g MachineMemOperands and dependence > information. > > > > Q1) I noticed that MachineMemOperands are lost when two LDRs are combined > and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. > > > > (before optimization) > > %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; > mem:LD4[%uglygep10] > > %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14, pred:%reg0; > mem:LD4[%uglygep2021] > > > > (after optimization) > > %reg1054<def>, %reg1033<def> = LDRD %reg1030, %reg0, 264, pred:14, &g...

...------- entry (0x8605ba0, LLVM BB @0x8602d30): %reg1024 = OR4 %r3, %r3 %reg1025 = OR4 %r4, %r4 %reg1026 = LWZ 0, %reg1025 %reg1027 = LIS <ga:.str_1> %reg1028 = LIS <ga:.str_2> %reg1029 = LBZ 0, %reg1026 ADJCALLSTACKDOWN 56 %reg1030 = IMPLICIT_DEF_GPR %reg1031 = LA %reg1027, <ga:.str_1> %r3 = OR4 %reg1031, %reg1031 BL <ga:printf>, %r3 %reg1032 = OR4 %r3, %r3 <------------------- %reg1033 = EXTSB %reg1029 %reg1034 = LA %reg1028, <ga:.str_2> ADJCAL...

...********** REWRITING TWO-ADDR INSTRS ********** > ********** Function: sext > %reg1028<def> = sextb_r %reg1025<kill> > prepend: %reg1028<def> = mov_rr %reg1025<kill> > rewrite to: %reg1028<def> = sextb_r %reg1028 > ... > %reg1030<def> = sextw_r %reg1026<kill> > prepend: %reg1030<def> = mov_rr %reg1026<kill> > rewrite to: %reg1030<def> = sextw_r %reg1030 > > Because sextb_r and sextw_r have destination tied to source operands, > TwoAddressInstructionPass thin...

...imp-def> %reg1097<def> = addC %reg1033<kill>, 0, %CCFLAGS<imp-def> %reg1098<def> = addC %reg1028<kill>, 0, %CCFLAGS<imp-def> %reg1099<def> = addC %reg1031<kill>, 0, %CCFLAGS<imp-def> %reg1100<def> = addC %reg1030, 0, %CCFLAGS<imp-def> %reg1101<def> = addC %reg1032<kill>, 0, %CCFLAGS<imp-def> %reg1102<def> = addC %reg1030<kill>, 0, %CCFLAGS<imp-def> br mbb<ifcont267,0x12bc518> Successors according to CFG: 0x12bc518 (#4) Do you hav...

...t;imp-def>, %ECX<imp-def,dead>, %EDI<imp-def,dead>, %EDX<imp-def,dead>, %ESI<imp-def,dead> 108 ADJCALLSTACKUP 0, 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> 116 %reg1029<def,dead> = MOV32rr %EAX, %RAX<imp-use,kill> 124 %reg1030<def> = MOV32r0 %EFLAGS<imp-def,dead> 132 %EAX<def> = MOV32rr %reg1030<kill> 140 RET %EAX<imp-use,kill>, %AX<imp-use,kill> ********** REGISTER MAP ********** [reg1024 -> EAX] [reg1025 -> R10] [reg1026 -> AH] [reg1027 -> XMM10] [reg1028 ->...

...def,dead>, %EDI<imp-def,dead>, > %EDX<imp-def,dead>, %ESI<imp-def,dead> > 108 ADJCALLSTACKUP 0, 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, > %ESP<imp-use> > 116 %reg1029<def,dead> = MOV32rr %EAX, %RAX<imp-use,kill> > 124 %reg1030<def> = MOV32r0 %EFLAGS<imp-def,dead> > 132 %EAX<def> = MOV32rr %reg1030<kill> > 140 RET %EAX<imp-use,kill>, %AX<imp-use,kill> > > > ********** REGISTER MAP ********** > [reg1024 -> EAX] > [reg1025 -> R10] > [reg1026 -> AH]...

...%reg1097<def> = addC %reg1033<kill>, 0, %CCFLAGS<imp-def> > %reg1098<def> = addC %reg1028<kill>, 0, %CCFLAGS<imp-def> > %reg1099<def> = addC %reg1031<kill>, 0, %CCFLAGS<imp-def> > %reg1100<def> = addC %reg1030, 0, %CCFLAGS<imp-def> > %reg1101<def> = addC %reg1032<kill>, 0, %CCFLAGS<imp-def> > %reg1102<def> = addC %reg1030<kill>, 0, %CCFLAGS<imp-def> > br mbb<ifcont267,0x12bc518> > Successors according to CFG: 0x12bc518 (#...

On Thu, 29 Jun 2006, Fernando Magno Quintao Pereira wrote: > I am working in a register allocator for LLVM, and I realized that, > after I perform register allocation, there is many move instructions that > are dead code, and can safely be removed. It is easy for the RA algorithm > to remove these instructions. It seems to me that the only instructions > with dead definitions

...ck into one vetor operation. // each %reg is a sub-register // r1, r2, r3, r4 here are virtual register number mul %reg1024, r1, r2 // x mul %reg1025, r1, r2 // y mul %reg1026, r1, r2 // z add %reg1027, r3, r4 // w sub %reg1028, %reg1024, r1 sub %reg1029, %reg1025, r1 sub %reg1030, %reg1026, r1 sub %reg1031, %reg1027, r1 So I decided to model each 4-element register as one Register in *.td file. Here are the details. Since all the 4 elements of a vector register occupy the same 'alloca', during the conversion of shader assembly to LLVM IR, I check if a vector re...

Dear guys, I am working in a register allocator for LLVM, and I realized that, after I perform register allocation, there is many move instructions that are dead code, and can safely be removed. It is easy for the RA algorithm to remove these instructions. It seems to me that the only instructions with dead definitions that I should not remove are the calls. Is it true? I would like to know

...ccording to CFG: BB#2 BB#3 %reg1026<def> = MOVr %reg1038<kill>, pred:14, pred:%reg0, opt:%reg0 %reg1027<def> = MOVr %reg1039<kill>, pred:14, pred:%reg0, opt:%reg0 %reg1028<def> = MOVr %reg1040<kill>, pred:14, pred:%reg0, opt:%reg0 %reg1030<def> = MOVr %reg1027<kill>, pred:14, pred:%reg0, opt:%reg0 %reg1037<def>, %reg1030<def> = LDR_POST %reg1030, %reg0, 4, pred:14, pred:%reg0 %reg1029<def> = ADDrr %reg1037<kill>, %reg1028, pred:14, pred:%reg0, opt:%reg0 %reg1031<def> =...

...b-register > // r1, r2, r3, r4 here are virtual register number > > mul %reg1024, r1, r2 // x > mul %reg1025, r1, r2 // y > mul %reg1026, r1, r2 // z > > add %reg1027, r3, r4 // w > > sub %reg1028, %reg1024, r1 > sub %reg1029, %reg1025, r1 > sub %reg1030, %reg1026, r1 > sub %reg1031, %reg1027, r1 > > So I decided to model each 4-element register as one Register in > *.td file. > > Here are the details. > > Since all the 4 elements of a vector register occupy the same > 'alloca', > during the conversion of...

...ed to align an address register to even boundary. Since address register can't be AND-ed with anything, I move the value into general purpose register, to "and" and then move it into address register. Unfortunately, the register allocator crashes. Here's machine code: %reg1030 = - %reg1027, 1 %reg1031 = move %reg1030 %reg1032 = + %reg1031, -2 %reg1033 = move %reg1032 %ar1 = load64 %gr1<def>, %reg1033 and here's assertion: llc: LiveIntervals.cpp:507: void llvm::LiveIntervals::joinIntervals(): Assertion `rcA == rcB && &q...

...1097<def> = addC %reg1033<kill>, 0, %CCFLAGS<imp-def> >> %reg1098<def> = addC %reg1028<kill>, 0, %CCFLAGS<imp-def> >> %reg1099<def> = addC %reg1031<kill>, 0, %CCFLAGS<imp-def> >> %reg1100<def> = addC %reg1030, 0, %CCFLAGS<imp-def> >> %reg1101<def> = addC %reg1032<kill>, 0, %CCFLAGS<imp-def> >> %reg1102<def> = addC %reg1030<kill>, 0, %CCFLAGS<imp-def> >> br mbb<ifcont267,0x12bc518> -- sorry about that, bu...

...elps reduce the number of register copies when setting up parameters for a call: %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,...

...VM BB @0x88be168, ID#1: Predecessors according to CFG: 0x88c7918 (#0) %reg1028 = LW 0, <fi#1> %reg1029 = LW 4, %reg1028 ADJCALLSTACKDOWN 0, %SP<imp-def>, %SP<imp-use> %4 = ADDu %ZERO, %reg1029 JAL <ga:atoi> ADJCALLSTACKUP 0, %SP<imp-def>, %SP<imp-use> %reg1030 = ADDu %ZERO, %2 SW %reg1030, 0, <fi#3> J mbb<cond_next,0x88c7e48> Successors according to CFG: 0x88c7e48 (#3) Total amount of phi nodes to update: 0 Lowered selection DAG: SelectionDAG has 5 nodes: 0x88c8eb0: ch = EntryToken 0x88c8f08: i32 = Constant <17000> 0x...

...%reg1027 = load <fi#-4> %reg1028 = move 1 setcc %reg1024, %reg1028 if v< goto %disp(label entry.selecttrue) %reg1071 = move 0 goto %disp(label entry.selectcont) entry.selecttrue (0x80659d0, LLVM BB @0x80639b0): %reg1070 = move 1 entry.selectcont (0x8065a30, LLVM BB @0x80638b0): %reg1030 = phi %reg1070, mbb<entry.selecttrue,0x80659d0>, %reg1071, mbb<entry,0x8065970> %reg1029 = move %reg1030 shortcirc_next.0 (0x8065a90, LLVM BB @0x805ffc8): %reg1031 = move 1 setcc %reg1026, %reg1031 if v< goto %disp(label shortcirc_next.0.selecttrue) %reg1073 = move 0 goto %dis...