search for: vreg25

...re actually none. What is happening is that although execution reaches to the line spiller().spill(LRE); inside RAGreedy::selectOrSplit() the insertion of the spill is avoided because the register gets rematted. This is the debug output I'm getting to show what I mean: Inline spilling DLDREGS:%vreg25,1.436782e-03 = [344r,640r:0) 0 at 344r >From original %vreg8,1.838235e-03 = [224r,640r:0) 0 at 224r Value %vreg25:0 at 344r may remat from %vreg25<def> = LDIWRdK 2; DLDREGS:%vreg25 remat: 632r %vreg28<def> = LDIWRdK 2; DLDREGS:%vreg28 640e %R15R14<def>...

On Nov 30, 2011, at 12:17 PM, Borja Ferrer wrote: > Thanks for all the hints Jakob, I've added the following piece of code after the spill code handling inside selectOrSplit() (ignoring some control logic): > > for (LiveIntervals::const_iterator I = LIS->begin(), E = LIS->end(); I != E; > ++I) > { > unsigned VirtReg = I->first; > if

...e. > What is happening is that although execution reaches to the line spiller().spill(LRE); inside RAGreedy::selectOrSplit() the insertion of the spill is avoided because the register gets rematted. This is the debug output I'm getting to show what I mean: > > Inline spilling DLDREGS:%vreg25,1.436782e-03 = [344r,640r:0) 0 at 344r > From original %vreg8,1.838235e-03 = [224r,640r:0) 0 at 224r > Value %vreg25:0 at 344r may remat from %vreg25<def> = LDIWRdK 2; DLDREGS:%vreg25 > remat: 632r %vreg28<def> = LDIWRdK 2; DLDREGS:%vreg28 > 640e %R1...

Thanks for all the hints Jakob, I've added the following piece of code after the spill code handling inside selectOrSplit() (ignoring some control logic): for (LiveIntervals::const_iterator I = LIS->begin(), E = LIS->end(); I != E; ++I) { unsigned VirtReg = I->first; if ((TargetRegisterInfo::isVirtualRegister(VirtReg)) && (VRM->getPhys(VirtReg)

...OPY %vreg19<kill>; R600_Reg128:%vreg23,%vreg19 %vreg23:sel_y<def> = COPY %vreg15<kill>; R600_Reg128:%vreg23 R600_TReg32:%vreg15 %vreg24<def> = COPY %vreg21<kill>; R600_Reg128:%vreg24,%vreg21 %vreg24:sel_y<def> = COPY %vreg2; R600_Reg128:%vreg24 R600_Reg32:%vreg2 %vreg25<def> = COPY %C1_Z; R600_Reg32:%vreg25 %vreg26<def> = COPY %vreg23<kill>; R600_Reg128:%vreg26,%vreg23 %vreg26:sel_z<def> = COPY %vreg16<kill>; R600_Reg128:%vreg26 R600_TReg32:%vreg16 %vreg27<def> = COPY %vreg24<kill>; R600_Reg128:%vreg27,%vreg24 %vreg27:sel_...

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

...gt;; R600_Reg128:%vreg23,%vreg19 > %vreg23:sel_y<def> = COPY %vreg15<kill>; R600_Reg128:%vreg23 R600_TReg32:%vreg15 > %vreg24<def> = COPY %vreg21<kill>; R600_Reg128:%vreg24,%vreg21 > %vreg24:sel_y<def> = COPY %vreg2; R600_Reg128:%vreg24 R600_Reg32:%vreg2 > %vreg25<def> = COPY %C1_Z; R600_Reg32:%vreg25 > %vreg26<def> = COPY %vreg23<kill>; R600_Reg128:%vreg26,%vreg23 > %vreg26:sel_z<def> = COPY %vreg16<kill>; R600_Reg128:%vreg26 R600_TReg32:%vreg16 > %vreg27<def> = COPY %vreg24<kill>; R600_Reg128:%vreg27,%vreg...

...vreg21,%vreg22 R600_Reg32:%vreg18 RESERVE_REG 0 %vreg23<def,tied1> = INSERT_SUBREG %vreg19<tied0>, %vreg15, sel_y; R600_Reg128:%vreg23,%vreg19 R600_TReg32:%vreg15 %vreg24<def,tied1> = INSERT_SUBREG %vreg21<tied0>, %vreg2, sel_y; R600_Reg128:%vreg24,%vreg21 R600_Reg32:%vreg2 %vreg25<def> = R600_LOAD_CONST 6; R600_Reg32:%vreg25 %vreg26<def,tied1> = INSERT_SUBREG %vreg23<tied0>, %vreg16, sel_z; R600_Reg128:%vreg26,%vreg23 R600_TReg32:%vreg16 RESERVE_REG 1 %vreg27<def,tied1> = INSERT_SUBREG %vreg24<tied0>, %vreg25<kill>, sel_z; R600_Reg128:%vre...

...Reg32:%vreg18 > RESERVE_REG 0 > %vreg23<def,tied1> = INSERT_SUBREG %vreg19<tied0>, %vreg15, sel_y; R600_Reg128:%vreg23,%vreg19 R600_TReg32:%vreg15 > %vreg24<def,tied1> = INSERT_SUBREG %vreg21<tied0>, %vreg2, sel_y; R600_Reg128:%vreg24,%vreg21 R600_Reg32:%vreg2 > %vreg25<def> = R600_LOAD_CONST 6; R600_Reg32:%vreg25 > %vreg26<def,tied1> = INSERT_SUBREG %vreg23<tied0>, %vreg16, sel_z; R600_Reg128:%vreg26,%vreg23 R600_TReg32:%vreg16 > RESERVE_REG 1 > %vreg27<def,tied1> = INSERT_SUBREG %vreg24<tied0>, %vreg25<kill>, sel_z; R...

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

Hi, 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 related commits later on, and the assertion I get on the latest trunk (r164162) differs from

...reg24<def> = COPY %vreg21<kill>; R600_Reg128:%vreg24,%vreg21 register: %vreg24 +[176r,256r:0) 192B%vreg24:sel_y<def> = COPY %vreg2; R600_Reg128:%vreg24 R600_Reg32:%vreg2 register: %vreg24 replace range with [176r,192r:1) RESULT: [176r,192r:1)[192r,256r:0)  0 at 192r 1 at 176r 208B%vreg25<def> = COPY %C1_Z; R600_Reg32:%vreg25 register: %vreg25 +[208r,272r:0) 224B%vreg26<def> = COPY %vreg23<kill>; R600_Reg128:%vreg26,%vreg23 register: %vreg26 +[224r,336r:0) 240B%vreg26:sel_z<def> = COPY %vreg16<kill>; R600_Reg128:%vreg26 R600_TReg32:%vreg16 register: %vr...

...lt;kill>; R600_Reg128:%vreg24,%vreg21 > register: %vreg24 +[176r,256r:0) > 192B%vreg24:sel_y<def> = COPY %vreg2; R600_Reg128:%vreg24 > R600_Reg32:%vreg2 > register: %vreg24 replace range with [176r,192r:1) RESULT: > [176r,192r:1)[192r,256r:0)  0 at 192r 1 at 176r > 208B%vreg25<def> = COPY %C1_Z; R600_Reg32:%vreg25 > register: %vreg25 +[208r,272r:0) > 224B%vreg26<def> = COPY %vreg23<kill>; R600_Reg128:%vreg26,%vreg23 > register: %vreg26 +[224r,336r:0) > 240B%vreg26:sel_z<def> = COPY %vreg16<kill>; R600_Reg128:%vreg26 > R600_TR...

...Start' failed. The following is the Machine IR and LiveVariables::ValInfo dump before and after PHI nodes elimination. 1. Before PHI nodes elimination. -Machine IR: BB#14: derived from LLVM BB %for.cond151.preheader Predecessors according to CFG: BB#12 BB#13 %vreg29<def> = PHI %vreg25, <BB#12>, %vreg28, <BB#13>; CPURegs:%vreg29,%vreg25,%vreg28 %vreg30<def> = PHI %vreg26, <BB#12>, %vreg27, <BB#13>; CPURegs:%vreg30,%vreg26,%vreg27 BNE %vreg81<kill>, %ZERO, <BB#17>; CPURegs:%vreg81 J <BB#15> Successors according to CFG...

...rated in your experience? Something that I noticed when experimenting with LLVM on our out-of-tree backend, was that there are copy instructions generated **because of** modulo scheduling. For example before modulo scheduling I have %vreg6<def> = PHI %vreg23, <BB#1>, %vreg17 %vreg25<def> = INSN1 %vreg1, %vreg6; % vreg26<def> = INSN1 %vreg2, %vreg6 <-- same opcode as previous insn % vreg17<def> = INSN2 %vreg6, %vreg5; So for the phi node here, if we do phi elimination and register coalescing, we won't have any copy insn left. But after modulo...

Hi - I replied to the original sender only by mistake. Sorry about that. When we started working on the pipeliner, and added it before the scheduler, we also were concerned that the scheduler or other passes would undo the work of the pipeliner. The initial thought was that we would add information (using metadata or some other way like you've suggested) to the basic block to tell the

..., t32, t34, t36, t38, t40 t57: i64 = extract_vector_elt t56, Constant:i64<0> t66: ch = CopyToReg t0, Register:i64 %vreg24, t57 t58: i64 = extract_vector_elt t56, Constant:i64<1> t68: ch = CopyToReg t0, Register:i64 %vreg25, t58 t59: i64 = extract_vector_elt t56, Constant:i64<2> t70: ch = CopyToReg t0, Register:i64 %vreg26, t59 t60: i64 = extract_vector_elt t56, Constant:i64<3> t72: ch = CopyToReg t0, Register:i64 %vreg27, t60...

Hi, I have some questions about the implementation of Software pipeline in MachinePipeliner.cpp. First, in hexagon backend, between MachinePipeliner and regalloc pass, there're some other passes like phi eliminate, two-address, register coalescing, which may change or insert intructions like 'copy' in MBB, and swp kernel loop may be destroyed by these passes. Why not put