search for: reg1027

...te this machine function: entry: 4 %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 %X...

...: > 4 %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> = FsMOV...

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

...gt; is 4 bytes fixed at location [SP-16] entry (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&...

...reg1025 = load <fi#-2> register: %reg1025 +[20,22) +[32,34) +[6,20) 8 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(lab...

...; > > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > > > > So their live ranges start at 28+2. > > Yep, this makes sense to me. But AL is a subregister of RAX too, > so shouldn't it have a live interval that starts there as well? > > 48 %EAX = MOV32rr %reg1027<kill>, %RAX<imp-use,kill>, %RAX<imp-def> > > MOV32rr %mreg(17)<d> %reg1027 %mreg(74) %mreg(74)<d> > > > > Def of sub-register use and define its super-register(s). > > I can't quite parse that. > > 48 %EAX = MOV32rr %reg1027<ki...

...ster allocation individually, it seems very difficult to merge 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 '...

...54:1) 0@? 1@? > > AL,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2@? > > AX,inf = [30,42:0)[50,54:1) 0@? 1@? > > EAX,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2 at 50 > > RAX,inf = [34,50:0)[50,54:1) 0@? 1 at 50 > > %reg1026,0 = [42,43:0) 0 at 42 > > %reg1027,0 = [46,50:0) 0@? > > > > Here's where the non-understanding happens. Why are the live > > ranges for the > > A machine registers so different? AL is defined in slot 30, which > > is an > > implicit def of AX, EAX and RAX due to aliasing, right? Only EAX...

...reg(99)<d> %mreg(100)<d> %mreg(101)<d> %mreg(102)<d> %mreg(17)<d> 36 ADJCALLSTACKUP 0, 0, %ESP<imp-def>, %ESP<imp-use> ADJCALLSTACKUP 0 0 %mreg(25)<d> %mreg(25) 40 %reg1026<dead> = MOV32rr %EAX<kill> MOV32rr %reg1026<d> %mreg(17) 44 %reg1027 = MOV32r0 MOV32r0 %reg1027<d> 48 %EAX = MOV32rr %reg1027<kill>, %RAX<imp-use,kill>, %RAX<imp-def> MOV32rr %mreg(17)<d> %reg1027 %mreg(74) %mreg(74)<d> 52 RET %EAX<imp-use,kill>, %RAX<imp-use,kill> RET %mreg(17) %mreg(74) (The CFE_* stuff is from our...

...re? Is it possible to model each case as a separate physical register? 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...

...** > AH,inf = [30,42:0)[50,54:1) 0@? 1@? > AL,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2@? > AX,inf = [30,42:0)[50,54:1) 0@? 1@? > EAX,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2 at 50 > RAX,inf = [34,50:0)[50,54:1) 0@? 1 at 50 > %reg1026,0 = [42,43:0) 0 at 42 > %reg1027,0 = [46,50:0) 0@? > > Here's where the non-understanding happens. Why are the live > ranges for the > A machine registers so different? AL is defined in slot 30, which > is an > implicit def of AX, EAX and RAX due to aliasing, right? Only EAX > is listed as > a...

...;>> AL,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2@? >>> AX,inf = [30,42:0)[50,54:1) 0@? 1@? >>> EAX,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2 at 50 >>> RAX,inf = [34,50:0)[50,54:1) 0@? 1 at 50 >>> %reg1026,0 = [42,43:0) 0 at 42 >>> %reg1027,0 = [46,50:0) 0@? >>> >>> Here's where the non-understanding happens. Why are the live >>> ranges for the >>> A machine registers so different? AL is defined in slot 30, which >>> is an >>> implicit def of AX, EAX and RAX due to aliasing,...

...is > I think so. LLVM is producing code 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 %reg10...

...die (last use). >> Again, what's >> the deal with RAX? EAX is redefined just a few instructions >> later, which >> should kill RAX. The [34,50:0)[50,54:1) interval for RAX is just >> weird. Why >> isn't it [34,54)? > > 48 %EAX = MOV32rr %reg1027<kill>, %RAX<imp-use,kill>, %RAX<imp-def> > MOV32rr %mreg(17)<d> %reg1027 %mreg(74) %mreg(74)<d> > > Def of sub-register use and define its super-register(s). So RAX's > live range isn't broken here. > >> >> Finally, according to th...

...FNSTCW16m <fi#0>, 1, %NOREG, 0 MOV8mi <fi#0>, 1, %NOREG, 1, 2 FLDCW16m <fi#0>, 1, %NOREG, 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>...

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

On Jan 19, 2009, at 9:17 AM, Patrick Boettcher wrote: > Hi list, > > in our LLVM-based-project we are writing a backend for our > processor. The > architecture is a quite straight-forward RISC, but it does not have > hardware interlocks, i.e. data hazards involving memory access must be > resolved by the compiler, either by scheduling unrelated > instructions or >

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

...etc. Sorry for using the wrong vocabulary. > It's not clear what kind of problems you are running it. When we limited our target to have only 3 registers available the code post-hazard-recognized looks like that: load 0x1234, reg1024 load 0x1236, reg1025 load 0x1238, reg1026 load 0x1240, reg1027 add reg1024, 1 add reg1025, 2 add reg1026, 3 add reg1027, 4 after register allocation: load 0x1234, reg1 load 0x1236, reg2 load 0x1238, reg3 add reg1, 1 add reg2, 2 add reg3, 3 store reg1, 0x1234 load 0x1240, reg1 add reg1, 4 Which won't work on our platform. It is missing 2 NOOPs after the...

Hi list, in our LLVM-based-project we are writing a backend for our processor. The architecture is a quite straight-forward RISC, but it does not have hardware interlocks, i.e. data hazards involving memory access must be resolved by the compiler, either by scheduling unrelated instructions or by inserting NOOPs into the load delay slots: ---- For example, code which looks like that: load