search for: selectorsplit

...2 $s23 $s24 $s25 $s26 $s27 and 35 more...>, implicit-def dead $lr, implicit $sp, implicit $r0, implicit $r1, implicit $r2, implicit-def $sp 352B ADJCALLSTACKUP 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 368B tBX_RET 14, $noreg # End machine code for function uECC_shared_secret. selectOrSplit tGPR:%2 [16r,320r:0) 0 at 16r weight:5.738636e-03 w=5.738636e-03 AllocationOrder(tGPR) = [ $r0 $r1 $r2 $r3 $r4 $r5 $r6 ] hints: $r2 Checking interference for %2 [16r,320r:0) 0 at 16r weight:5.738636e-03 $r2: IK_RegMask $r0: IK_RegMask $r1: IK_RegMask $r3: IK_RegMask $r4: IK_Free missed hint $r2 a...

...The problem here is that it had previously allocated V15 (V15_l is a sub-register of V15) to %vreg304. %vreg304 is defined at 6768B and finally used at 6804B so the instruction LOAD_v4i16 at 6796B ends up clobbering the value in V15 before its last use. This is the output of the allocator itself: selectOrSplit VRF64_l:%vreg375 [6796r,6800r:0) 0 at 6796r w=1.#INF00e+00 assigning %vreg375 to %V15_l: V15_e0 [6796r,6800r:0) 0 at 6796r V15_e1 [6796r,6800r:0) 0 at 6796r V15_e2 [6796r,6800r:0) 0 at 6796r V15_e3 [6796r,6800r:0) 0 at 6796r And this is the live range of %vreg304 printed just before the alloc...

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) == REG_Y)) { Liv...

If I'm understanding what's going on in this test correctly, what's happening is: * ARMTargetLowering::LowerCall prefers indirect calls when a function is called at least 3 times in minsize * In thumb 1 (without -fno-omit-frame-pointer) we have effectively only 3 callee-saved registers (r4-r6) * The function has three arguments, so those three plus the register we need to hold the

...s19 $s20 $s21 $s22 $s23 $s24 $s25 $s26 $s27 and 35 more...>, implicit-def dead $lr, implicit $sp, implicit $r0, implicit $r1, implicit $r2, implicit-def $sp 448B ADJCALLSTACKUP 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 464B tBX_RET 14, $noreg # End machine code for function f. selectOrSplit tGPR:%0 [48r,416r:0) 0 at 48r weight:6.575521e-03 w=6.575521e-03 AllocationOrder(tGPR) = [ $r0 $r1 $r2 $r3 $r4 $r5 $r6 ] hints: $r0 $r1 $r2 missed hint $r0 assigning %0 to $r4: R4 [48r,416r:0) 0 at 48r selectOrSplit tGPR:%1 [32r,400r:0) 0 at 32r weight:7.890625e-03 w=7.890625e-03 hints: $r1 $r0...

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 ((TargetRegisterInfo::isVirtualRegister(VirtReg)) > && (VRM->getPhys(...

Jakob I've just noticed that I'm getting false positives about spills when there are 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...

...mm1, %xmm3, %xmm4 ... Here, we have a spill and reload to keep the constant in a register for a single use! *** Live-Range Splitting Looking at the first constant, we can see that the copies are inserted by the greedy register allocator when it splits the live range. The main entry point is selectOrSplit. In brief: 1) The constant is assigned and evicted several times. Eventually selectOrSplit decides to split the live-range. This splits the interval in two, creating two new intervals (A and B). At the boundary of the intervals a copy is inserted that copies between the virtual registers. 2)...

...Z which also belongs to the PTR RC, try to evict: call canEvictInterference() for virtZ which interferes with virtY, both VirtReg.isSpillable() and Intf->isSpillable() return false, can't evict, wait for a second round and queue new interval. 4) do some work unrelated to these vregs. 5) when selectOrSplit is called again for virtZ it falls through down to the return ~0u line and fails. This issue can be very easily reproduced with the Thumb2 target by doing the following few changes: 1) declare a PTRRC regclass in ARMRegisterInfo.td with only one physreg: def PTRRC : RegisterClass<"ARM&qu...

On Dec 8, 2011, at 12:15 PM, Borja Ferrer wrote: > Jakob I've just noticed that I'm getting false positives about spills when there are 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 %...

On Nov 29, 2011, at 10:24 AM, Borja Ferrer wrote: > Yes, I want the register to be allocatable when there are no stack frames used in the function so it can be used for other purposes. In fact, I looked at how other backends solve this problem, but they are all too conservative by always reserving the register which in my case it is not a good solution because of the performance impact of not

On Dec 17, 2012, at 8:38 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello, > > I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: > > struct ss > { > int a; > int b; > int c; > }; > void

Yes, I want the register to be allocatable when there are no stack frames used in the function so it can be used for other purposes. In fact, I looked at how other backends solve this problem, but they are all too conservative by always reserving the register which in my case it is not a good solution because of the performance impact of not having this register available. I find very interesting

...he PTR RC, try to evict: call > canEvictInterference() for virtZ which interferes with virtY, both > VirtReg.isSpillable() and Intf->isSpillable() return false, can't evict, > wait for a second round and queue new interval. > 4) do some work unrelated to these vregs. > 5) when selectOrSplit is called again for virtZ it falls through down to > the return ~0u line and fails. > > > This issue can be very easily reproduced with the Thumb2 target by doing > the following few changes: > > 1) declare a PTRRC regclass in ARMRegisterInfo.td with only one physreg: > def...

...ver very similar, except that there becomes two COPYs back to sibling value after the loop. My apologies [vregs 76->111, 87->122]. 1. The interval for %vreg111 first covers nearly the entire function. Then it gets split into two intervals, where one covers the inner loops, which makes sense. selectOrSplit %vreg111 [68r,400B:1)[400B,688r:6)[688r,752B:4)[752B,1264r:6)[1264r,1312r:3)[1312r,1472B:2)[1472B,1520r:5)[1520r,3488B:0) 0 at 1520r 1 at 68r 2 at 1312r 3 at 1264r 4 at 688r 5 at 1472B-phi 6 at 400B-phi w=3.181050e-02 ... queuing new interval: %vreg121 [1764r,2936r:0)[2960B,2980r:0) 0 at 1764r qu...

Hello, I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: struct ss { int a; int b; int c; }; void loop(struct ss *x, struct ss **y, int z) { int i; for (i=0; i<z; ++i) { x->c += y[i]->b; } } The problem relies in

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Akira Hatanaka" <ahatanak at gmail.com> > Sent: Saturday, April 6, 2013 11:56:28 AM > Subject: Re: [LLVMdev] [PATCH]

...= COPY %vreg4<kill>; GPRegs:%vreg4 192B RET %R2<imp-use> # End machine code for function isZero. ********** DEBUG VARIABLES ********** ********** Compute Spill Weights ********** ********** Function: isZero ********** GREEDY REGISTER ALLOCATION ********** ********** Function: isZero selectOrSplit GPRegs:%vreg0 [16r,32r:0) 0 at 16r AllocationOrder(GPRegs) = [ %R1 %R2 %R3 %R4 %R5 %R20 %R21 %R22 %R23 %R24 %R25 %R26 %R27 %R28 %R29 %R6 %R7 %R8 %R9 %R10 %R11 %R12 %R13 %R14 %R15 %R16 %R17 %R18 %R19 ] assigning %vreg0 to %R2: R2 selectOrSplit GPRegs:%vreg4 [160r,176r:0) 0 at 160r assigning %vreg...

...ecomes two COPYs back to sibling value after the loop. My apologies [vregs 76->111, 87->122]. >> >> 1. >> The interval for %vreg111 first covers nearly the entire function. Then it gets split into two intervals, where one covers the inner loops, which makes sense. >> selectOrSplit %vreg111 [68r,400B:1)[400B,688r:6)[688r,752B:4)[752B,1264r:6)[1264r,1312r:3)[1312r,1472B:2)[1472B,1520r:5)[1520r,3488B:0) 0 at 1520r 1 at 68r 2 at 1312r 3 at 1264r 4 at 688r 5 at 1472B-phi 6 at 400B-phi w=3.181050e-02 >> … >> queuing new interval: %vreg121 [1764r,2936r:0)[2960B,2980r:0...

...kill>, 0, 0, 0, 1, pred:%PRED_SEL_OFF, 0; R600_Reg32:%vreg49,%vreg38 1152BJUMP <BB#1>, pred:%noreg    Successors according to CFG: BB#1 # End machine code for function main. ********** DEBUG VARIABLES ********** ********** GREEDY REGISTER ALLOCATION ********** ********** Function: main selectOrSplit R600_Reg128:%vreg1 [16r,32r:0)[32r,48r:1)[48r,64r:2)[64r,848r:3)[880B,1168B:3)  0 at 16r 1 at 32r 2 at 48r 3 at 64r AllocationOrder(R600_Reg128) = [ %T1_XYZW %T2_XYZW %T3_XYZW %T4_XYZW %T5_XYZW %T6_XYZW %T7_XYZW %T8_XYZW %T9_XYZW %T10_XYZW %T11_XYZW %T12_XYZW %T13_XYZW %T14_XYZW %T15_XYZW %T16_XYZW...