search for: vreg16

...<+208>: mr r3,r3 > > > > and the RA should eliminate trivial copies. On PPC, normal moves are encoded as OR instructions where the two operands being ORed together are the same. These self moves, as it turns out, come from things like this: %vreg18<def> = OR8To4 %vreg16, %vreg16; GPRC:%vreg18 G8RC:%vreg16 This is generated from the pattern: def : Pat<(i32 (trunc G8RC:$in)), (OR8To4 G8RC:$in, G8RC:$in)>; So, as far as RA is concerned, this is a "real" operation (a binary OR which truncates the result to 32-bits (from 64-bit inputs)). In...

...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 %vreg17<def> = COPY %vreg14:sel_y; R600_Reg32:%vreg17 R600_Reg128:%vreg14 %T2_Z<def> = COPY %vreg16; R600_Reg32:%vreg16 %T2_W<def> = COPY %vreg17; R600_Reg32:...

Hi Hal, On 07/06/2012 09:57, Chandler Carruth wrote: > On Wed, Jun 6, 2012 at 10:37 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > I am working on cleaning up some PPC code generation. Two questions: > > 1. Which pass is responsible for cleaning up self-moves: > 0x00000000100057c0 <+208>: mr r3,r3 > and

...ding to CFG: BB#2(0x30000000 / 0x80000000 = 37.50%) > BB#3(0x50000000 / 0x80000000 = 62.50%) > 23 > 24 BB#2: derived from LLVM BB %if.then2 > 25 Predecessors according to CFG: BB#1 > 26 ADJCALLSTACKDOWN 96, %R1<imp-def,dead>, %R1<imp-use> > 27 %vreg16<def> = COPY %vreg15; G8RC:%vreg16,%vreg15 > 28 BL8_NOP <ga:@callVoid>, <regmask **LONG LIST**>, > %X3<imp-def,dead> > 29 ADJCALLSTACKUP 96, 0, %R1<imp-def,dead>, %R1<imp-use> > 30 ADJCALLSTACKDOWN 96, %R1<imp-def,dead>...

...ccurs 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 %vreg15<def> = COPY %T1_Y; R600_...

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

...7, 2012, at 1:42 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On PPC, normal moves are encoded as OR instructions where the two > operands being ORed together are the same. These self moves, as it > turns out, come from things like this: > > %vreg18<def> = OR8To4 %vreg16, %vreg16; GPRC:%vreg18 G8RC:%vreg16 > > This is generated from the pattern: > > def : Pat<(i32 (trunc G8RC:$in)), > (OR8To4 G8RC:$in, G8RC:$in)>; > > So, as far as RA is concerned, this is a "real" operation (a binary OR > which truncates the resu...

...n Jun 7, 2012, at 1:42 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On PPC, normal moves are encoded as OR instructions where the two > operands being ORed together are the same. These self moves, as it > turns out, come from things like this: > > %vreg18<def> = OR8To4 %vreg16, %vreg16; GPRC:%vreg18 G8RC:%vreg16 > > This is generated from the pattern: > > def : Pat<(i32 (trunc G8RC:$in)), > (OR8To4 G8RC:$in, G8RC:$in)>; > > So, as far as RA is concerned, this is a "real" operation (a binary OR > which truncates the resu...

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

...<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 %vreg15<def> = COPY %T1_Y; R600_...

...2> 22 Successors according to CFG: BB#2(0x30000000 / 0x80000000 = 37.50%) BB#3(0x50000000 / 0x80000000 = 62.50%) 23 24 BB#2: derived from LLVM BB %if.then2 25 Predecessors according to CFG: BB#1 26 ADJCALLSTACKDOWN 96, %R1<imp-def,dead>, %R1<imp-use> 27 %vreg16<def> = COPY %vreg15; G8RC:%vreg16,%vreg15 28 BL8_NOP <ga:@callVoid>, <regmask **LONG LIST**>, %X3<imp-def,dead> 29 ADJCALLSTACKUP 96, 0, %R1<imp-def,dead>, %R1<imp-use> 30 ADJCALLSTACKDOWN 96, %R1<imp-def,dead>, %R1<imp-use>...

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

...t;kill> // R2 = R4 could be optimized to -> %R2D<def> = LA %R2D<kill>, 4, %noreg // R2 = R2 + 4 The reason this wasn't coalesced, is because of overlapping during coalescing: 864B %vreg11<def> = LA %vreg2, 4, %noreg 880B %vreg16<def> = LLCMux %vreg2, 4, %noreg 928B %vreg2<def> = COPY %vreg11 It seems that if this had been rescheduled to 880B %vreg16<def> = LLCMux %vreg2, 4, %noreg 864B %vreg11<def> = LA %vreg2, 4, %noreg 928B %vreg2<def> = COPY %...

...8RC:%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](tbaa=!4) G8RC:%vreg17 G8RC_and_G8RC_NOX0:%vreg1 400B %vreg19<def> = LD 40, %vreg0; mem:LD8[%arrayidx.5](tbaa...

...f>, %P1<imp-def>, %P2<imp-def>, %P3<imp-def>, %P15<imp-def>, %RT<imp-def>, %P0<imp-use>, %P1<imp-use>, %P2<imp-use>, %P3<imp-use>; dbg:../src/getbits.c:57:5 496B ADJCALLSTACKUP 0, 0, pred:%noreg, %SP<imp-def>, %SP<imp-use> 512B %vreg16<def> = LDUBri %vreg8, 1, pred:%noreg; mem:LD1[getelementptr inbounds (%struct.FIFO* @fifo, i32 0, i32 1)] IntRegs:%vreg16,%vreg8 dbg:../src/getbits.c:53:3 544B %vreg17<def,tied1> = CMPEQANDri %vreg17<tied0>, %vreg16<kill>, 0, pred:%noreg; PredRegs:%vreg17 IntRegs:%vreg16 db...

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

...still virtual when lowering custom Emitter instructions. However the RegisterCoalescer pass does not preserve TargetFlag in the JoinCopy() member function. For instance, here is some output of the regalloc pass (TF=2 corresponds to a Neg TargetFlag) : 352B    %vreg20:sel_x<def,undef> = COPY %vreg16<kill>[TF=2], %vreg20<imp-def>; R600_Reg128:%vreg20 R600_Reg32:%vreg16     Considering merging %vreg16 with %vreg20:sel_x     Cross-class to R600_Reg128.         RHS = %vreg16 = [304r,352r:0)  0 at 304r         LHS = %vreg20 = [352r,400r:0)  0 at 352r         updated: 304B    %vreg20:sel...

...--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%vreg14<def> = COPY %T1_X<kill>; R600_TReg32:%vreg14 register: %vreg14 +[64r,96r:0) 80B%vreg18&...

...reg48 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%vreg14<def> = COPY %T1_X<kill>; R600_TReg32:%vreg14 > register: %vreg14...

...94 %vreg195<def> = MOV32ri 8; GR32:%vreg195 %EAX<def> = COPY %vreg195; GR32:%vreg195 WIN_ALLOCA %EAX<imp-def,dead>, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> %vreg196<def> = COPY %ESP; GR32:%vreg196 MOV32mr %vreg196, 1, %noreg, 0, %noreg, %vreg16; mem:ST4[%114] GR32:%vreg196,%vreg16 %vreg197<def> = MOV32ri 72; GR32:%vreg197 %EAX<def> = COPY %vreg197; GR32:%vreg197 WIN_ALLOCA %EAX<imp-def,dead>, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> %vreg198<def> = COPY %ESP; GR32:%vreg198 MOVSDm...