search for: vreg14

...el_y; R600_Reg128:%vreg11,%vreg9 R600_Reg32:%vreg8 %vreg13<def> = IMPLICIT_DEF; R600_Reg32:%vreg13 %vreg12<def,tied1> = INSERT_SUBREG %vreg11<tied0>, %vreg13, sel_z; R600_Reg128:%vreg12,%vreg11 R600_Reg32:%vreg13 RESERVE_REG 3 %vreg15<def> = IMPLICIT_DEF; R600_Reg32:%vreg15 %vreg14<def,tied1> = INSERT_SUBREG %vreg12<tied0>, %vreg15, sel_w; R600_Reg128:%vreg14,%vreg12 R600_Reg32:%vreg15 %T2_X<def> = COPY %vreg3; R600_TReg32:%vreg3 %vreg16<def> = COPY %vreg14:sel_x; R600_Reg32:%vreg16 R600_Reg128:%vreg14 %T2_Y<def> = COPY %vreg2; R600_TReg32:%vreg2...

...pily move a machine instruction into a following machine basic block (not necessarily a successor), even when that later block can be reached through a setjmp. Here is some example debug output from llc that I'm seeing: Sinking along critical edge. Sink instr %vreg8<def,tied1> = ADD64rr %vreg14<tied0>, %vreg31, %EFLAGS<imp-def,dead>; GR64:%vreg8,%vreg14,%vreg31 into block BB#11: Predecessors according to CFG: BB#8 BB#10 BB#32 ... EH_SjLj_Setup <BB#36>, <regmask> Successors according to CFG: BB#34 BB#36 Sinking along critical edge. Sink inst...

...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:%vreg16 %v...

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

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

...32 %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:%vreg16 %v...

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

...reg97 t63: i64 = shl t4, Constant:i8<2> t4: i64,ch = CopyFromReg t0, Register:i64 %vreg11 t3: i64 = Register %vreg11 t1889: i8 = Constant<2> t5: i64 = Constant<4> t10: i64 = undef t16: v32i32,ch = CopyFromReg t0, Register:v32i32 %vreg14 t15: v32i32 = Register %vreg14 In function: int_to_uchar -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170921/07970914/attachment.html>

...g4 %vreg3<def> = OR8To4 %vreg2<kill>, %vreg2; GPRC:%vreg3 G8RC:%vreg2 %vreg9<def> = COPY %vreg4<kill>; GPRC:%vreg9,%vreg4 %vreg10<def> = RLDICL %vreg9<kill>, 0, 32; GPRC:%vreg10,%vreg9 %vreg11<def> = MTCTR8r %vreg10<kill>; CTRRC8:%vreg11 GPRC:%vreg10 %vreg14<def> = COPY %vreg11<kill>; CTRRC8:%vreg14,%vreg11 Successors according to CFG: BB#1 128B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN Predecessors according to CFG: BB#0 BB#1 %vreg12<def> = COPY %vreg14<kill>; CTRRC8:%vreg12,%vreg14 %vreg5<def> =...

...8RC:%vreg10 G8RC_and_G8RC_NOX0:%vreg0 224B %vreg11<def> = LD 16, %vreg1; mem:LD8[%arrayidx2.2](tbaa=!4) G8RC:%vreg11 G8RC_and_G8RC_NOX0:%vreg1 272B %vreg13<def> = LD 24, %vreg0; mem:LD8[%arrayidx.3](tbaa=!4) G8RC:%vreg13 G8RC_and_G8RC_NOX0:%vreg0 288B %vreg14<def> = LD 24, %vreg1; mem:LD8[%arrayidx2.3](tbaa=!4) G8RC:%vreg14 G8RC_and_G8RC_NOX0:%vreg1 336B %vreg16<def> = LD 32, %vreg0; mem:LD8[%arrayidx.4](tbaa=!4) G8RC:%vreg16 G8RC_and_G8RC_NOX0:%vreg0 352B %vreg17<def> = LD 32, %vreg1; mem:LD8[%arrayidx2.4](tba...

...gt;, pred:%noreg Successors according to CFG: BB#5 304B BB#3: Predecessors according to CFG: BB#2 336B %vreg26<def> = COPY %P0; IntRegs:%vreg26 Successors according to CFG: BB#4 352B BB#4: derived from LLVM BB %while.body Predecessors according to CFG: BB#4 BB#3 400B %vreg14<def> = LDUBrr %vreg8, 0, pred:%noreg; mem:LD1[getelementptr inbounds (%struct.FIFO* @fifo, i32 0, i32 0)] IntRegs:%vreg14,%vreg8 dbg:../src/getbits.c:56:5 416B STBrr %vreg26, 0, %vreg14<kill>, pred:%noreg; mem:ST1[%p.04] IntRegs:%vreg26,%vreg14 dbg:../src/getbits.c:56:5 432B %vreg27&l...

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some

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

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

On Jul 8, 2012, at 3:42 PM, Sergei Larin <slarin at codeaurora.org> wrote: > ********** EXPANDING POST-RA PSEUDO INSTRS ********** > ********** Function: main > real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, > %D7<imp-def> > replaced by: %R15<def> = TFR %R4, %D7<imp-def> > > The R4 is a subreg of D2 double

..._NOX0:%vreg0 >> 224B %vreg11<def> = LD 16, %vreg1; mem:LD8[%arrayidx2.2](tbaa=!4) G8RC:%vreg11 G8RC_and_G8RC_NOX0:%vreg1 >> 272B %vreg13<def> = LD 24, %vreg0; mem:LD8[%arrayidx.3](tbaa=!4) G8RC:%vreg13 G8RC_and_G8RC_NOX0:%vreg0 >> 288B %vreg14<def> = LD 24, %vreg1; mem:LD8[%arrayidx2.3](tbaa=!4) G8RC:%vreg14 G8RC_and_G8RC_NOX0:%vreg1 >> 336B %vreg16<def> = LD 32, %vreg0; mem:LD8[%arrayidx.4](tbaa=!4) G8RC:%vreg16 G8RC_and_G8RC_NOX0:%vreg0 >> 352B %vreg17<def> = LD 32, %vreg1; mem:LD8[%a...

Hello everyone, I am running into an obscure issue with ExpandPostRA. Does anyone recognizes the following: The pass replaces a real copy with a "transfer" instruction: ********** EXPANDING POST-RA PSEUDO INSTRS ********** ********** Function: main real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, %D7<imp-def> replaced by:

...180<kill>; CPURegs:%vreg29,%vreg180 %vreg30<def> = COPY %vreg181<kill>; CPURegs:%vreg30,%vreg181 BEQ %vreg81, %ZERO, <BB#15>; CPURegs:%vreg81 Successors according to CFG: BB#15 BB#20 BB#20: Predecessors according to CFG: BB#14 %vreg187<def> = COPY %vreg14<kill>; CPURegs:%vreg187,%vreg14 %vreg188<def> = COPY %vreg29<kill>; CPURegs:%vreg188,%vreg29 J <BB#17> Successors according to CFG: BB#17 BB#15: derived from LLVM BB %for.body156.preheader Predecessors according to CFG: BB#14 BB#17: derived from LLVM BB %fo...

...i <ga:@callee_stack8>, 0, <regmask>, %XSP<imp-use>, %X0<imp-use>, %X1<imp-use>, %X2<imp-use>, %X3<imp-use>, %X4<imp-use>, %X5<imp-use>, %X6<imp-use>, %X7<imp-use> %vreg15<def> = COPY %vreg7:sub_32; GPR32:%vreg15 GPR64:%vreg7 %vreg14<def> = COPY %vreg6:sub_32; GPR32:%vreg14 GPR64:%vreg6 %vreg13<def> = COPY %vreg5:sub_32; GPR32:%vreg13 GPR64:%vreg5 %vreg12<def> = COPY %vreg4:sub_32; GPR32:%vreg12 GPR64:%vreg4 %vreg11<def> = COPY %vreg3:sub_32; GPR32:%vreg11 GPR64:%vreg3 %vreg10<def> = COPY %vreg...