search for: vreg1

Hi, I'm facing a problem in my BE while trying to remove certain copies. Here is a code snippet which I would like to optimize %vreg1<def> = READF32r; vRRegs:%vreg1 %vreg2<def> = COPY %vreg1:rsub_h; iRSubRegs:%vreg2 vRRegs:%vreg1 %vreg3<def> = COPY %vreg1:rsub_l; iRSubRegs:%vreg3 vRRegs:%vreg1 This code produces subreg-to-subreg copies but I would like to have direct uses of vreg1's subregisters instead. I...

...re should be a bug somewhere else. > It seems the PhiElim is working correctly, the output of --debug-only=regalloc shows that %vreg48 is a phi-join register, and intervals looks correct to me : ********** COMPUTING LIVE INTERVALS ********** ********** Function: main BB#0:# derived from  16B%vreg17<def> = COPY %T1_W<kill>; R600_TReg32:%vreg17 register: %vreg17 +[16r,352r:0) 32B%vreg16<def> = COPY %T1_Z<kill>; R600_TReg32:%vreg16 register: %vreg16 +[32r,240r:0) 48B%vreg15<def> = COPY %T1_Y<kill>; R600_TReg32:%vreg15 register: %vreg15 +[48r,160r:0) 64B%vreg1...

...Matthias Am 10/8/13, 11:03 AM, schrieb Akira Hatanaka: > Hi, > > I have a question about the way sub-registers are spilled and restored > that is related to the changes I made in r192119. > > Suppose I have the following piece of code with four > instructions. %vreg0 and %vreg1 consist of two sub-registers indexed > by sub_lo and sub_hi. > > instr0 %vreg0<def> > instr1 %vreg1:sub_lo<def,read-undef> > instr2 %vreg0<use> > instr3 %vreg1:sub_hi<def> > > If register allocator decides to insert spill and restore instructions &g...

...> > It seems the PhiElim is working correctly, the output of --debug-only=regalloc > shows that %vreg48 is a phi-join register, and intervals looks correct to me : > > ********** COMPUTING LIVE INTERVALS ********** > ********** Function: main > BB#0:# derived from  > 16B%vreg17<def> = COPY %T1_W<kill>; R600_TReg32:%vreg17 > register: %vreg17 +[16r,352r:0) > 32B%vreg16<def> = COPY %T1_Z<kill>; R600_TReg32:%vreg16 > register: %vreg16 +[32r,240r:0) > 48B%vreg15<def> = COPY %T1_Y<kill>; R600_TReg32:%vreg15 > register: %vreg1...

On Mar 28, 2012, at 7:41 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi, > > I'm facing a problem in my BE while trying to remove certain copies. > Here is a code snippet which I would like to optimize > > %vreg1<def> = READF32r; vRRegs:%vreg1 > %vreg2<def> = COPY %vreg1:rsub_h; iRSubRegs:%vreg2 vRRegs:%vreg1 > %vreg3<def> = COPY %vreg1:rsub_l; iRSubRegs:%vreg3 vRRegs:%vreg1 > > This code produces subreg-to-subreg copies but I would like to have > direct uses of vreg1'...

...cussion regarding subregisters. But I think the problem posted by Mikael just happened to involve subregisters, and the discussions about subregisters is confusing when it comes to Mikaels original question/problem. I think that the bundle could look something like this just as well: BUNDLE %vreg1<def,dead> * %vreg1<def> = add %vreg2, %vreg3 * call @foo, %vreg1<internal-use> No subregisters involved. %vreg1 is dead after the bundle. %vreg1 is not dead when defined at the "add", because it is used later in the same bundle. Should perhaps the %vreg1...

Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. vreg10 only appears in BB#3, and the join only occurs in BB#3 apparently even if vreg32 lives in the 4 machine blocks After joining, there are still vreg32 occurence in the machinefunction dump.  Before, the MF dump is : _________________ # Machine code for function main: Post SSA Fun...

...I_V4 <ga:@xx_stack>; IntRegs:%vreg4 > Successors according to CFG: BB#1 > > BB#1: derived from LLVM BB %for.cond > Predecessors according to CFG: BB#0 BB#1 > %vreg0<def> = PHI %vreg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 > %vreg1<def> = PHI %vreg5, <BB#0>, %vreg2, <BB#1>; IntRegs:%vreg1,%vreg5,%vreg2 > %vreg2<def> = LDriw %vreg0<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg2,%vreg0 > %vreg3<def> = ADD_ri %vreg2, 8; IntRegs:%vreg3,%vreg2 > %vreg6<def> = CMPEQri %v...

...subregisters calls 'ssub_0' and 'ssub_1' which would result in 'S4' and 'S5' getting used if 'D2' is assigned to the virtual register later. Typical operations are decomposing wider values or composing wide values with multiple smaller defs: Decomposing: %vreg1<def> = produce a 'D' value = use 'S' value %vreg1:ssub_0 = use 'S' value %vreg1:ssub_1 Composing: %vreg1:ssub_0<def,read-undef> = produce an 'S' value %vreg1:ssub_1<def> = produce an 'S' value...

Hi Vincent, On 25/10/2012 18:14, Vincent Lejeune wrote: > When examining the debug output of regalloc, it seems that joining 32bits reg also joins 128 parent reg. > > If I look at the : > %vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 > > instructions ; it gets joined to : > 928B%vreg34<def> = COPY %vreg48:sel_y; > > when vreg6 and

...%vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4 Successors according to CFG: BB#1 BB#1: derived from LLVM BB %for.cond Predecessors according to CFG: BB#0 BB#1 %vreg0<def> = PHI %vreg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 %vreg1<def> = PHI %vreg5, <BB#0>, %vreg2, <BB#1>; IntRegs:%vreg1,%vreg5,%vreg2 <<<<<<<<<<< Use of that dummy value. %vreg2<def> = LDriw %vreg0<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg2,%vreg0 By the time it has gotten to the sc...

...; > Am 10/8/13, 11:03 AM, schrieb Akira Hatanaka: > > Hi, > > I have a question about the way sub-registers are spilled and restored > that is related to the changes I made in r192119. > > Suppose I have the following piece of code with four > instructions. %vreg0 and %vreg1 consist of two sub-registers indexed by > sub_lo and sub_hi. > > instr0 %vreg0<def> > instr1 %vreg1:sub_lo<def,read-undef> > instr2 %vreg0<use> > instr3 %vreg1:sub_hi<def> > > If register allocator decides to insert spill and restore instructions...

...Ivan On 25/10/2012 23:01, Vincent Lejeune wrote: > Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. > I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. > vreg10 only appears in BB#3, and the join only occurs in BB#3 apparently even if vreg32 lives in the 4 machine blocks > After joining, there are still vreg32 occurence in the machinefunction dump. > > Before, the MF dump is : > _________________ > # Machine code for...

...I_V4 <ga:@xx_stack>; IntRegs:%vreg4 > Successors according to CFG: BB#1 > > BB#1: derived from LLVM BB %for.cond > Predecessors according to CFG: BB#0 BB#1 > %vreg0<def> = PHI %vreg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 > %vreg1<def> = PHI %vreg5, <BB#0>, %vreg2, <BB#1>; IntRegs:%vreg1,%vreg5,%vreg2 <<<<<<<<<<< Use of that dummy value. > %vreg2<def> = LDriw %vreg0<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg2,%vreg0 > > > By the time it has...

...ction : before RegCoalescing, the machine code is : > > // BEFORE LOOP > ... Some COPYs.... > 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2 > 416B%vreg48<def> = COPY %vreg3<kill>; R600_Reg128:%vreg48,%vreg3 > 432B%vreg49<def> = COPY %vreg13<kill>; R600_Reg32:%vreg49,%vreg13 > Successors according to CFG: BB#1 > > > // LOOP CONDITION > 464B%vreg5<def> = COPY %vreg47<kill>; R600_Reg32:%vreg5,%vreg47 > 480B%vreg6<def> = COPY %vreg48<kill>; R600_Reg128:%vreg6,%vreg48 > 496B%vreg7&lt...

...distinct registers. > b) The first two are in a consecutive pair (second > first) > c) The second two are in a consecutive pair (fourth > third) Constraints b & c are OK, but a is too strict : "mpra %R0, %R1, %R0, %R1" is OK. But I though, may be wrongly, that "mpra %vreg1, %vreg2, %vreg3, %vreg4" meant %vreg1 and %vreg3 will be allocated to different physical registers, or they would have been coalesced. For example, the pass I added after the coalescer ensures that instructions like "mpra %vreg1, %vreg2, %vreg1, %vreg4" (impossible for pbqp to solve)...

...part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : // BEFORE LOOP ... Some COPYs.... 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2 416B%vreg48<def> = COPY %vreg3<kill>; R600_Reg128:%vreg48,%vreg3 432B%vreg49<def> = COPY %vreg13<kill>; R600_Reg32:%vreg49,%vreg13    Successors according to CFG: BB#1 // LOOP CONDITION 464B%vreg5<def> = COPY %vreg47<kill>; R600_Reg32:%vreg5,%vreg47 480B%vreg6<def> = COPY %vreg48<kill>; R600_Reg128:%vreg6,%vreg48 496B%vreg7<def> = COPY %vreg49<kill&gt...

...grouped together at the start of the function. Those loads use 12 registers before any of the divides are scheduled. As a result, we end up with significantly higher register pressure after all the loads. -- 0B BB#0: derived from LLVM BB %entry Live Ins: %X3 %X4 16B %vreg1<def> = COPY %X4; G8RC_and_G8RC_NOX0:%vreg1 32B %vreg0<def> = COPY %X3; G8RC_and_G8RC_NOX0:%vreg0 48B %vreg2<def> = LD 0, %vreg0; mem:LD8[%num](tbaa=!4) G8RC:%vreg2 G8RC_and_G8RC_NOX0:%vreg0 64B %vreg3<def> = LD 0, %vreg1; mem:LD8[%den](tb...

...gh level. At the machine level it looks like it is the register coalescer that is duplicating the constant. It transforms 0B BB#0: derived from LLVM BB %entry 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, <ga:@val>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg0 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg1 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; mem:ST8[@p](tbaa=!"any pointer") GR64:%vreg1,%vreg0 64B %vreg2<def> = MOV64ri 12345123400; GR64:%vreg2 80B...

...t; Am 10/8/13, 11:03 AM, schrieb Akira Hatanaka: >> Hi, >> >> I have a question about the way sub-registers are spilled and restored that is related to the changes I made in r192119. >> >> Suppose I have the following piece of code with four instructions. %vreg0 and %vreg1 consist of two sub-registers indexed by sub_lo and sub_hi. >> >> instr0 %vreg0<def> >> instr1 %vreg1:sub_lo<def,read-undef> >> instr2 %vreg0<use> >> instr3 %vreg1:sub_hi<def> >> >> If register allocator decides to insert spill and...