search for: reg1028

...3 sextw r2 mov r1,r2 ### unnecessary move add r1,r4 jmp [r30] Which should be this: sext: sextb r1 add r1,r3 sextw r2 add r1,r2 jmp [r30] The debug 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&...

...setcc %reg1024, %reg1025 12 goto %disp(label then) 16 goto %disp(label else) then: 20 %reg1026 = + %reg1025, %reg1024 register: %reg1026 +[22,26) 24 %gr7 = move %reg1026 register: gr7 dead +[26,27) 28 return else: 32 %reg1027 = + %reg1025, %reg1024 register: %reg1027 +[34,35) 36 %gr7 = move %reg1028 register: gr7 dead +[38,39) 40 return ********** JOINING INTERVALS *********** entry: 0 %reg1024 = load <fi#-1> 4 %reg1025 = load <fi#-2> 8 setcc %reg1024, %reg1025 12 goto %disp(label then) 16 goto %disp(label else) then: 20 %reg1026 = + %reg1025, %reg1024 24 %gr7 = move %reg1026 28...

...ister: R14W live through +[0,40:0) livein register: R14B dead +[0,3:0) livein register: 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]...

Greg McGary wrote: > ********** 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> =...

...BB @0x12bb900, ID#2: Predecessors according to CFG: 0x12bc290 (#0) 0x12bca70 (#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&lt...

...025, %R13W in reg%1026, %R12W in reg%1027 BB#0: derived from LLVM BB %entry 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 functi...

...%reg1024<def,dead> = MOV32rr %EDI<kill> 12 %reg1025<def,dead> = MOV64rr %RSI<kill> 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> 28 %reg1026<def> = MOV8ri 4 36 %reg1027<def> = FsFLD0SD 44 %reg1028<def> = LEA64r %reg0, 1, %reg0, <ga:.str1> 52 %RDI<def> = MOV64rr %reg1028<kill> 60 %XMM0<def> = FsMOVAPDrr %reg1027 68 %XMM1<def> = FsMOVAPDrr %reg1027 76 %XMM2<def> = FsMOVAPDrr %reg1027 84 %XMM3<def> = FsMOVAPDrr %reg1027&lt...

...ry (0x8681458): %reg1024 = load <fi#-1> %reg1025 = load <fi#-2> setcc %reg1024, %reg1025 goto %disp(label then) goto %disp(label else) then (0x8681688): %reg1026 = + %reg1025, %reg1024 %gr7 = move %reg1026 return else (0x86815e0): %reg1027 = + %reg1025, %reg1024 %gr7 = move %reg1028 return # End machine code for _Z3addii(). Code after register allocation # Machine code for _Z3addii(): <fi #-2> is 4 bytes fixed at location [SP-20] <fi #-1> is 4 bytes fixed at location [SP-16] <fi #0> is 4 bytes <fi #1> is 4 bytes <fi #2> is 4 bytes en...

On Wed, 9 Jun 2004, Vladimir Prus wrote: > Chris Lattner wrote: > > > Thanks, this works! I don't yet understand why spill code is needed there > > > at all, but I'll return to that when I have branches working correctly. > > > > I'm not sure either. Can you send the code before and after register > > allocation? > > Attached. Okay, yeah

...Successors according to CFG: BB#3 BB#3: derived from LLVM BB %bb Predecessors according 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 %reg...

...V32rr %EDI<kill> > 12 %reg1025<def,dead> = MOV64rr %RSI<kill> > 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, > %ESP<imp-use> > 28 %reg1026<def> = MOV8ri 4 > 36 %reg1027<def> = FsFLD0SD > 44 %reg1028<def> = LEA64r %reg0, 1, %reg0, <ga:.str1> > 52 %RDI<def> = MOV64rr %reg1028<kill> > 60 %XMM0<def> = FsMOVAPDrr %reg1027 > 68 %XMM1<def> = FsMOVAPDrr %reg1027 > 76 %XMM2<def> = FsMOVAPDrr %reg1027 > 84 %XMM3<def>...

...D#2: > Predecessors according to CFG: 0x12bc290 (#0) 0x12bca70 (#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> >...

...de like this one here, before RA: ---------------------------------------------------------------------------- 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 <--------------...

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

...llocFast's way of saying "Oops, I clobbered the return value from your CALL. Didn't think you would need it." The problem 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)...

...gorithm. RALocal folds spills and restores into other instructions. 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...

...)[134,146:1) 0 at 0*-(94) 1 at 134-(146) 28 %reg1024<def> = MOVRdRr %R15<kill> Inspecting R15,inf = [0,30:0)[126,146:1) 0 at 0*-(30) 1 at 126-(146) and %reg1024,0.000000e+00 = [30,38:0) 0 at 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...

...and see if it helps the problem. > > I've updated and rebuild. The bug is still there and the output you've asked > for is attached. Okay, it looks like a bug in your code generator (though the linscan allocator should give a better assertion). Specifically, you never define the %reg1028 register. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/

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