search for: reg1029

...R13W live through +[0,40:0) livein register: R13B dead +[0,3:0) livein register: R12W live through +[0,40:0) livein register: R12B dead +[0,3:0) 4 %reg1028<def> = MOV16rm %reg0, <ga:@b>; mem:LD2[@b] register: %reg1028 +[6,14:0) 12 %reg1029<def> = MOV16rr %reg1028<kill> register: %reg1029 +[14,30:0) 20 %reg1029<def> = ADD16rm %reg1029, %reg0, <ga:@a>, %SRW<imp-def>; mem:LD2[@a] register: %reg1029 replace range with [14,22:1) RESULT: %reg1029,0.000000e+00 = [14,22:1)[22,30:0) 0...

On Sep 4, 2010, at 11:21 AM, Borja Ferrer wrote: > I've noticed this pattern happening with other operators aswell, but used xor in this example. As i said before, i tried with different register allocation orders, but it will produce always the same result. GCC is emitting longer code, but since LLVM is so nearer to the optimal code sequence i wanted to reach it. In LLVM, copies are

...,dead>, %XMM15<imp-def,dead>, %EFLAGS<imp-def,dead>, %EAX<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] [r...

...f,dead>, %EFLAGS<imp-def,dead>, > %EAX<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 *****...

...ntry Live Ins: %R15W %R14W %R13W %R12W %reg1027<def> = MOV16rr %R12W %reg1026<def> = MOV16rr %R13W %reg1025<def> = MOV16rr %R14W %reg1024<def> = MOV16rr %R15W %reg1028<def> = MOV16rm %reg0, <ga:@b>; mem:LD2[@b] %reg1029<def> = ADD16rm %reg1028, %reg0, <ga:@a>, %SRW<imp-def,dead>; mem:LD2[@a] SUB16mr %reg0, <ga:@r>, %reg1029, %SRW<imp-def,dead>; mem:ST2[@r] LD2[@r] RET # End machine code for function test. # Machine code for function test: Function Live Ins: %R15W in...

...30-(38): Joined. Result = R15,inf = [0,38:0)[126,146:1) 0 at 0*-(38) 1 at 126-(146) 44 %reg1028<def> = MOVRdRr %R0<kill> Inspecting R0,inf = [38,46:0)[54,62:1)[94,102:2) 0 at 38-(46) 1 at 54-(62) 2 at 94-(102) and %reg1028,0.000000e+00 = [46,86:0) 0 at 46-(86): Interference! 60 %reg1029<def> = MOVRdRr %R0<kill> Inspecting R0,inf = [38,46:0)[54,62:1)[94,102:2) 0 at 38-(46) 1 at 54-(62) 2 at 94-(102) and %reg1029,0.000000e+00 = [62,134:0) 0 at 62-(134): Interference! 68 %reg1030<def> = MOVRdRr %R1<kill> Inspecting R1,inf = [38,39:0)[54,70:1)[94,95:2) 0...

...---------------------------------------------------------------------- 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...

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

...x12bca70 (#1) %reg1033<def> = addC %reg1025<kill>, 0, %CCFLAGS<imp-def,dead> %reg1032<def> = addC %reg1024<kill>, 0, %CCFLAGS<imp-def,dead> %reg1095<def> = addC %reg1028, 0, %CCFLAGS<imp-def> %reg1096<def> = addC %reg1029<kill>, 0, %CCFLAGS<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>...

...rge the scalars operations back 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 LL...

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

On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: > If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. > Tried it, and it seems to break quite a big chunk of our tests on SPU :) Before r103488 ("Mostly rewrite RegAllocFast") there was no problem. But with r103488, I get a:

I just changed the default register allocator for -O0 builds to the fast allocator. This means that the local register allocator is not used anymore, and since it does more or less the same as the fast allocator, there is no reason to keep it around. I am going to delete it in a week or two. If you are using the local register allocator, please try switching to the fast allocator and report any

...t; %reg1033<def> = addC %reg1025<kill>, 0, %CCFLAGS<imp-def,dead> > %reg1032<def> = addC %reg1024<kill>, 0, %CCFLAGS<imp-def,dead> > %reg1095<def> = addC %reg1028, 0, %CCFLAGS<imp-def> > %reg1096<def> = addC %reg1029<kill>, 0, %CCFLAGS<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...

...Evan > // 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...

...oblem is this code: BB#0: derived from LLVM BB %0 BRASL <ga:@extFunc>, %R0<imp-def>, %R1<imp-def>, %R3<imp-def>, %R0<imp-use>, ... %reg1028<def> = ILv4i32 0 %reg1027<def> = ORi64_v2i64 %reg1028 ADJCALLSTACKUP 0, %R1<imp-def>, %R1<imp-use> %reg1029<def> = LRr32 %R3 The return value from the call is in %R3, but %reg1027 and %reg1028 are also allocated to %R3 before it is copied to a safe place (%reg1029). RegAllocFast does not distinguish between call-clobbered registers and return value registers. They are all considered 'free'...

...ons. RAFast doesn't bother because debug builds have very few spills. RAFast uses more aggressive hinting by peeking at future instructions. This helps 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...

...REG, 0 %reg1024 = MOV32rm <fi#-2>, 1, %NOREG, 0 %reg1025 = MOV32rm %reg1024, 1, %NOREG, 0 %reg1026 = MOVSX32rm8 %reg1025, 1, %NOREG, 0 %reg1027 = MOVSX32rm8 %reg1025, 1, %NOREG, 1 ADJCALLSTACKDOWN 8 %reg1028 = 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...

...8c8d58, 0x88ca250, 0x88c8aa0, 0x88c8d58:1 SU(4): 0x88c8c50: ch = TokenFactor 0x88ca2b8, 0x88ca310 SU(5): 0x88c8dd0: ch = J 0x88c8a38, 0x88c8c50 Selected machine code: cond_true: 0x88c79a8, LLVM 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...

...eg0, 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> = SUBri %reg1026<kill>, 1, pred:14, pred:%reg0, opt:%reg0 CMPzri %reg1031, 0, pred:14, pred:%reg0, %CPSR<imp-def> %reg1038<def> = MOVr %reg1031<kill>...