search for: t1_x

...%23, i32 6)   %24 = extractelement <4 x float> %9, i32 3   call void @llvm.AMDGPU.store.output(float %24, i32 7)   ret void } # *** IR Dump Before Expand ISel Pseudo-instructions ***: # Machine code for function main: SSA Function Live Ins: %T1_W in %vreg0, %T1_Z in %vreg1, %T1_Y in %vreg2, %T1_X in %vreg3 Function Live Outs: %T1_W %T1_Z %T1_Y %T1_X %T2_W %T2_Z %T2_Y %T2_X BB#0: derived from LLVM BB %0     Live Ins: %T1_W %T1_Z %T1_Y %T1_X %vreg3<def> = COPY %T1_X; R600_TReg32:%vreg3 %vreg2<def> = COPY %T1_Y; R600_TReg32:%vreg2 %vreg1<def> = COPY %T1_Z; R600_TReg32:%vreg1...

...undef, i32 %29, i32 0   %57 = shufflevector <1 x i32> %56, <1 x i32> %55, <1 x i32> <i32 1>   %58 = extractelement <1 x i32> %57, i32 0   br label %25 } # *** IR Dump Before Expand ISel Pseudo-instructions ***: # Machine code for function main: SSA Function Live Ins: %T1_X in %vreg14, %T1_Y in %vreg15, %T1_Z in %vreg16, %T1_W in %vreg17 Function Live Outs: %T1_W %T1_Z %T1_Y %T1_X %T2_W %T2_Z %T2_Y %T2_X BB#0: derived from LLVM BB %0     Live Ins: %T1_X %T1_Y %T1_Z %T1_W %vreg17<def> = COPY %T1_W; R600_TReg32:%vreg17 %vreg16<def> = COPY %T1_Z; R600_TReg32...

...hufflevector <1 x i32> %56, <1 x i32> %55, <1 x i32> <i32 1> > %58 = extractelement <1 x i32> %57, i32 0 > br label %25 > } > # *** IR Dump Before Expand ISel Pseudo-instructions ***: > # Machine code for function main: SSA > Function Live Ins: %T1_X in %vreg14, %T1_Y in %vreg15, %T1_Z in %vreg16, %T1_W in %vreg17 > Function Live Outs: %T1_W %T1_Z %T1_Y %T1_X %T2_W %T2_Z %T2_Y %T2_X > > BB#0: derived from LLVM BB %0 > Live Ins: %T1_X %T1_Y %T1_Z %T1_W > %vreg17<def> = COPY %T1_W; R600_TReg32:%vreg17 > %vreg16<def...

...g10 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 Function Live Ins: %T1_X in %vreg14, %T1_Y in %vreg15, %T1_Z in %vreg16, %T1_W in %vreg17 Function Live Outs: %T1_W %T1_Z %T1_Y %T1_X %T2_W %T2_Z %T2_Y %T2_X BB#0: derived from LLVM BB %0     Live Ins: %T1_X %T1_Y %T1_Z %T1_W %vreg17<def> = COPY %T1_W; R600_TReg32:%vreg17 %vreg16<def> = COPY %T1_Z; R600_TReg32...

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

...d 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 > Function Live Ins: %T1_X in %vreg14, %T1_Y in %vreg15, %T1_Z in %vreg16, %T1_W in %vreg17 > Function Live Outs: %T1_W %T1_Z %T1_Y %T1_X %T2_W %T2_Z %T2_Y %T2_X > > BB#0: derived from LLVM BB %0 > Live Ins: %T1_X %T1_Y %T1_Z %T1_W > %vreg17<def> = COPY %T1_W; R600_TReg32:%vreg17 > %vreg16<def...

...nverted to vreg = COPY %PhysReg after instruction selection. For instance, the following sample was generated when EnablePhysicalJoin is true : # Machine code for function main: Post SSA, not tracking liveness Function Live Ins: %T2_X in %vreg0, %T1_W in %vreg1, %T1_Z in %vreg2, % T1_Y in %vreg3, %T1_X in %vreg4 BB#0: derived from LLVM BB %main_body Live Ins: %T2_X %T1_W %T1_Z %T1_Y %T1_X %T1_X<def,undef> = KILL %T1_X<kill,undef>, %T1_XYZW<imp-def,undef> R600_Export %T1_XYZW<kill>, 0, 0, 0, 1, 2, 3 %T2_X<def,undef> = KILL %T2_X<kill,undef>, %T2...

...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%vreg14<def> = COPY %T1_X<kill>; R600_TReg32:%vreg14 register: %vreg14 +[64r,96r:0) 80B%vreg18<def> = COPY %C1_X; R600_Reg32:%vreg18 register: %vreg18 +[80r,128r:0) 96B%vreg19:sel_x<def,read-undef> = COPY %vreg14<kill>; R600_Reg128:%vreg19 R600_TReg32:%vreg14 register: %vreg19 +[96r,144r:0) 112B%vreg...

...%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%vreg14<def> = COPY %T1_X<kill>; R600_TReg32:%vreg14 > register: %vreg14 +[64r,96r:0) > 80B%vreg18<def> = COPY %C1_X; R600_Reg32:%vreg18 > register: %vreg18 +[80r,128r:0) > 96B%vreg19:sel_x<def,read-undef> = COPY %vreg14<kill>; > R600_Reg128:%vreg19 R600_TReg32:%vreg14 > register:...

...generates the following MC in both plain LLVM 3.4 and LLVM 3.4 with my patch applied right after the "Finalize machine instruction bundles" pass: %T0_W<def> = LSHL_eg 0, 0, 1, 0, 0, 0, %T0_W<kill>, 0, 0, 0, -1, %ALU_LITERAL_X, 0, 0, 0, -1, 1, pred:%PRED_SEL_OFF, 3, 0 %T1_X<def> = LSHL_eg 0, 0, 1, 0, 0, 0, %T1_W<kill>, 0, 0, 0, -1, %T0_W, 0, 0, 0, -1, 1, pred:%PRED_SEL_OFF, 0, 0, %T1_XYZW<imp-def> %T1_W<def> = LSHL_eg 0, 0, 1, 0, 0, 0, %ALU_LITERAL_X, 0, 0, 0, -1, %T0_W<kill>, 0, 0, 0, -1, 1, pred:%PRED_SEL_OFF, 255, 0, %T1_XYZW<im...

Hi Tom, Thanks a lot for your explanations, now it makes a lot more sense ;) I had a slightly closer look at the R600 packetizer, and the issue is that the third LSHL instruction has both an implicit use and *afterwards* an implicit def of T1_XYZW. The latter def causes the current ScheduleDAGInstrs implementation to ignore the implicit use, thus the ScheduleDAG only contains an anti-dependency from the second to the third LSHL and the packetizer can bundle the instructions. If the order of the implicit-defs and implicit-use would be...