search for: vreg15

...;ve attempted a very large number of tweaks to the costs > (both existing and experimental ones that I've added). However, despite all > of that, I can't seem to get RA to split the following: > > 1 BB#0: derived from LLVM BB %entry > 2 Live Ins: %X3 > 3 %vreg15<def> = COPY %X3; G8RC:%vreg15 > 4 %vreg4<def> = CMPLDI %vreg15, 0; CRRC:%vreg4 G8RC:%vreg15 > 5 %vreg11:sub_32<def,read-undef> = LI 0; G8RC:%vreg11 > 6 BCC 68, %vreg4, <BB#1>; CRRC:%vreg4 > 7 Successors according to CFG: BB#4(0...

...than allocating a CSR. I've attempted a very large number of tweaks to the costs (both existing and experimental ones that I've added). However, despite all of that, I can't seem to get RA to split the following: 1 BB#0: derived from LLVM BB %entry 2 Live Ins: %X3 3 %vreg15<def> = COPY %X3; G8RC:%vreg15 4 %vreg4<def> = CMPLDI %vreg15, 0; CRRC:%vreg4 G8RC:%vreg15 5 %vreg11:sub_32<def,read-undef> = LI 0; G8RC:%vreg11 6 BCC 68, %vreg4, <BB#1>; CRRC:%vreg4 7 Successors according to CFG: BB#4(0x30000000 / 0x800000...

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

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:

...SERT_SUBREG %vreg9<tied0>, %vreg8<kill>, sel_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:%vre...

...nd 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 %vreg15<def> =...

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

...B#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_TReg3...

...7 = 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 %vreg15<def> =...

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

...8RC_and_G8RC_NOX0:%vreg1 424B %vreg4<def> = DIVD %vreg2, %vreg3; G8RC:%vreg4,%vreg2,%vreg3 432B %vreg9<def> = DIVD %vreg7, %vreg8; G8RC:%vreg9,%vreg7,%vreg8 440B %vreg12<def> = DIVD %vreg10, %vreg11; G8RC:%vreg12,%vreg10,%vreg11 448B %vreg15<def> = DIVD %vreg13, %vreg14; G8RC:%vreg15,%vreg13,%vreg14 456B %vreg18<def> = DIVD %vreg16, %vreg17; G8RC:%vreg18,%vreg16,%vreg17 464B %vreg21<def> = DIVD %vreg19, %vreg20; G8RC:%vreg21,%vreg19,%vreg20 472B %vreg5<def> = ADDIStocHA %X2, &...

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

...********** 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<def> = COPY %C1_X; R600_Reg32:%vreg18 register: %vreg18 +[80r,128r:0) 96B%vreg19:sel_x<def,...

...LS ********** > ********** 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<def> = COPY %C1_X; R600_Reg32:%vreg18 > register: %vreg18 +[80r,128r:0)...

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

...424B %vreg4<def> = DIVD %vreg2, %vreg3; G8RC:%vreg4,%vreg2,%vreg3 >> 432B %vreg9<def> = DIVD %vreg7, %vreg8; G8RC:%vreg9,%vreg7,%vreg8 >> 440B %vreg12<def> = DIVD %vreg10, %vreg11; G8RC:%vreg12,%vreg10,%vreg11 >> 448B %vreg15<def> = DIVD %vreg13, %vreg14; G8RC:%vreg15,%vreg13,%vreg14 >> 456B %vreg18<def> = DIVD %vreg16, %vreg17; G8RC:%vreg18,%vreg16,%vreg17 >> 464B %vreg21<def> = DIVD %vreg19, %vreg20; G8RC:%vreg21,%vreg19,%vreg20 >> 472B %vreg5<def...

...28:%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_x<def,undef> = MUL %vreg3:sel_x<kill>, %vreg15; R600_Reg128:%vreg20,%vreg3 R600_Reg32:%vreg15     Joined. Result = %vreg20 = [304r,400r:0)  0 at 304r I'd like to prevent this specific join from occuring, because DST register cannot be negated. Is there a way to control the JoinCopy function from RegisterCoalescer ? Or is there any way to d...

...t: Re: [llvm-dev] [GlobalISel] [X86] unable to legalize instruction Sorry for the late follow-up. Here is the output with the suggested option: $ llc -global-isel -pass-remarks-missed="gisel-*" simple_foo.ll LLVM ERROR: unable to legalize instruction: %vreg17<def>(s32) = G_SDIV %vreg15, %vreg16; (in function: foo) Thanks for any help/suggestions. On Wed, Oct 11, 2017 at 8:13 PM, Aditya Nandakumar <proaditya at gmail.com<mailto:proaditya at gmail.com>> wrote: I believe if you pass(iirc) -pass-remarks-missed=“gisel-*”, it’ll print the instruction it failed to legalize...

I believe if you pass(iirc) -pass-remarks-missed=“gisel-*”, it’ll print the instruction it failed to legalize. Sent from my iPhone > On Oct 11, 2017, at 6:44 PM, S. Bharadwaj Yadavalli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks for your quick reply. > > Here its is: > > =========== > > ; ModuleID = 'simple_foo.c' > source_filename

...R64:%vreg18 %X7<def> = COPY %vreg18; GPR64:%vreg18 TC_RETURNdi <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 %vreg...