search for: 16r

Hi, I am debugging private backend and faced interesting problem: sometimes spill hoisting creates double stores. (some output from -debug-only=regalloc). First hoisting: Checking redundant spills for 0 at 16r in %vreg19 [16r,144B:0)[144B,240B:1)[240B,280r:2)[296r,416B:3)[416B,456r:4)[472r,592B:5) 0 at 16r 1 at 144B-phi 2 at 240B-phi 3 at 296r 4 at 416B-phi 5 at 472r Merged to stack int: SS#0 [16r,592B:0) 0 at x hoisted: 16r STbo %vreg19, <fi#0> Second below: Checking redundant spills for 0...

...er instruction, for the life of the instruction like I would expect. The verifier does not like it however: $ llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx906 -verify-machineinstrs -run-pass=machine-scheduler -o - -verify-misched foo.mir # Before machine scheduling. ********** INTERVALS ********** %0 [16r,16d:1)[32r,32d:0) 0 at 32r 1 at 16r weight:0.000000e+00 RegMasks: ********** MACHINEINSTRS ********** # Machine code for function multiple_connected_components_dead: NoPHIs, TracksLiveness 0B bb.0: 16B dead %0:vgpr_32 = V_MOV_B32_e32 0, implicit $exec 32B dead %0:vgpr_...

..., the output of --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...

...c > 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:%vreg1...

...er instruction, for the life of the instruction like I would expect. The verifier does not like it however: $ llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx906 -verify-machineinstrs -run-pass=machine-scheduler -o - -verify-misched foo.mir # Before machine scheduling. ********** INTERVALS ********** %0 [16r,16d:1)[32r,32d:0) 0 at 32r 1 at 16r weight:0.000000e+00 RegMasks: ********** MACHINEINSTRS ********** # Machine code for function multiple_connected_components_dead: NoPHIs, TracksLiveness 0B bb.0: 16B dead %0:vgpr_32 = V_MOV_B32_e32 0, implicit $exec 32B dead %0:vgpr_...

...value only exists due to this identity copy in %bb.1, which is removed. When the copy is erased and the interval is updated (https://github.com/llvm/llvm-project/blob/523cc097fdafa1bb60373dcc70df7dfd31551f56/llvm/lib/CodeGen/RegisterCoalescer.cpp#L1871), the new live interval looks like this: %0 [16r,32B:2)[32B,96r:0)[96r,128B:1) 0 at 32B-phi 1 at 96r 2 at 16r L0000000000000003 [32B,80B:0) 0 at 32B-phi // sub0 This remaining [32B,80B:0) across %bb.1 is a fake phi-only segment. If I freshly recompute LiveIntervals, the subrange is empty as it should be. The verifier doesn't care about t...

...-units in ABI blocks. 0B %bb.0 R0#0 R1#0 R2#0 Created 3 new intervals. ********** INTERVALS ********** R0 [0B,48r:0)[96r,144r:3)[192r,240r:2)[288r,336r:1) 0 at 0B-phi 1 at 288r 2 at 192r 3 at 96r R1 [0B,32r:0)[112r,144r:3)[208r,240r:2)[304r,336r:1) 0 at 0B-phi 1 at 304r 2 at 208r 3 at 112r R2 [0B,16r:0)[128r,144r:3)[224r,240r:2)[320r,336r:1) 0 at 0B-phi 1 at 320r 2 at 224r 3 at 128r %0 [48r,288r:0) 0 at 48r weight:0.000000e+00 %1 [32r,304r:0) 0 at 32r weight:0.000000e+00 %2 [16r,320r:0) 0 at 16r weight:0.000000e+00 %3 [80r,336r:0) 0 at 80r weight:0.000000e+00 RegMasks: 144r 240r 336r *****...

...r32 = MOV32ri 17 > JMP_1 %bb.3 > > bb.2: > NOOP implicit %0 > %1 = COPY %0 > JMP_1 %bb.3 > > bb.3: > NOOP implicit %1 > > > > $ llc -run-pass=liveintervals -debug-only=regalloc test.mir > ********** INTERVALS ********** > %0 [16r,64B:0)[112B,144r:0) 0 at 16r weight:0.000000e+00 > %1 [80r,112B:1)[144r,176B:0)[176B,192r:2) 0 at 144r 1 at 80r 2 at 176B-phi weight:0.000000e+00 > RegMasks: > ********** MACHINEINSTRS ********** > # Machine code for function somefunc: NoPHIs > > 0B bb.0: > successors: %b...

...de: 16B %vreg0:ssub_0<def,read-undef> = ... 32B %vreg0:ssub_1<def> = ... 48B = %vreg0 64B = %vreg0:ssub_0 80B %vreg0 = ... 96B = %vreg0:ssub_1 will be represented as the following live range(s): Common LiveRange: [16r,32r)[32r,64r),[80r,96r) SubRange with Mask 0x0004 (=ssub_0): [16r,64r)[80r,80d) SubRange with Mask 0x0008 (=ssub_1): [32r,48r)[80r,96r) Patches/Changes: * Moves live range management code in the LiveInterval class to a new class LiveRange, move the previous LiveRange class (which was just...

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

...> > NOOP implicit %0 > > %1 = COPY %0 > > JMP_1 %bb.3 > > > > bb.3: > > NOOP implicit %1 > > > > > > > > $ llc -run-pass=liveintervals -debug-only=regalloc test.mir > > ********** INTERVALS ********** > > %0 [16r,64B:0)[112B,144r:0) 0 at 16r weight:0.000000e+00 > > %1 [80r,112B:1)[144r,176B:0)[176B,192r:2) 0 at 144r 1 at 80r 2 at 176B-phi > weight:0.000000e+00 > > RegMasks: > > ********** MACHINEINSTRS ********** > > # Machine code for function somefunc: NoPHIs > > > &g...

The phi instruction is irrelevant; just the way I think about things. The question is if the allocator believes that t0 and t2 interfere. Perhaps the coalescing example was too simple. In the general case, we can't coalesce without a notion of interference. My worry is that looking at interference by ranges of instruction numbers leads to inaccuracies when a range is introduced by a copy.

...32B %vreg0:ssub_1<def> = ... > 48B = %vreg0 > 64B = %vreg0:ssub_0 > 80B %vreg0 = ... > 96B = %vreg0:ssub_1 > > will be represented as the following live range(s): > > Common LiveRange: [16r,32r)[32r,64r),[80r,96r) > SubRange with Mask 0x0004 (=ssub_0): [16r,64r)[80r,80d) > SubRange with Mask 0x0008 (=ssub_1): [32r,48r)[80r,96r) > > Patches/Changes: > * Moves live range management code in the LiveInterval class to a new > class LiveRange, mov...

...Created 3 new intervals. ********** INTERVALS ********** R0 [0B,48r:0)[96r,144r:4)[192r,240r:3)[288r,336r:2)[384r,432r:1) 0 at 0B-phi 1 at 384r 2 at 288r 3 at 192r 4 at 96r R1 [0B,32r:0)[112r,144r:4)[208r,240r:3)[304r,336r:2)[400r,432r:1) 0 at 0B-phi 1 at 400r 2 at 304r 3 at 208r 4 at 112r R2 [0B,16r:0)[128r,144r:4)[224r,240r:3)[320r,336r:2)[416r,432r:1) 0 at 0B-phi 1 at 416r 2 at 320r 3 at 224r 4 at 128r %0 [48r,416r:0) 0 at 48r weight:0.000000e+00 %1 [32r,400r:0) 0 at 32r weight:0.000000e+00 %2 [16r,320r:0) 0 at 16r weight:0.000000e+00 %3 [80r,432r:0) 0 at 80r weight:0.000000e+00 RegMask...

...COPY %vreg4<kill>; GPRegs:%vreg4 192B RET %R2<imp-use,kill> # End machine code for function isZero. ********** COMPUTING LIVE INTERVALS ********** ********** Function: isZero BB#0: # derived from entry 16B %vreg0<def> = COPY %R2<kill>; GPRegs:%vreg0 register: %vreg0 +[16r,32r:0) 32B STWi13 <fi#1>, 0, %vreg0<kill>; mem:ST4[%a.addr] GPRegs:%vreg0 BB#1: # derived from if.then 64B %vreg3<def> = MOVri 1; GPRegs:%vreg3 register: %vreg3 +[64r,80r:0) 80B STWi13 <fi#0>, 0, %vreg3<kill>; mem:ST4[%retval] GPRegs:%vreg3 BB#2: # derived from if....

...b.3 > >> > > >> > bb.3: > >> > NOOP implicit %1 > >> > > >> > > >> > > >> > $ llc -run-pass=liveintervals -debug-only=regalloc test.mir > >> > ********** INTERVALS ********** > >> > %0 [16r,64B:0)[112B,144r:0) 0 at 16r weight:0.000000e+00 > >> > %1 [80r,112B:1)[144r,176B:0)[176B,192r:2) 0 at 144r 1 at 80r 2 at 176B-phi > weight:0.000000e+00 > >> > RegMasks: > >> > ********** MACHINEINSTRS ********** > >> > # Machine code for functio...

...reg0:ssub_1<def> = ... >> 48B = %vreg0 >> 64B = %vreg0:ssub_0 >> 80B %vreg0 = ... >> 96B = %vreg0:ssub_1 >> >> will be represented as the following live range(s): >> >> Common LiveRange: [16r,32r)[32r,64r),[80r,96r) >> SubRange with Mask 0x0004 (=ssub_0): [16r,64r)[80r,80d) >> SubRange with Mask 0x0008 (=ssub_1): [32r,48r)[80r,96r) >> >> Patches/Changes: >> * Moves live range management code in the LiveInterval class to a new >> class LiveRange,...

Hi Vincent, On 24/10/2012 23:26, Vincent Lejeune wrote: > Hi, > > I don't know if my llvm ir code is faulty, or if I spot a bug in the RegisterCoalescing Pass, so I'm posting my issue on the ML. Shader and print-before-all dump are given below. > > The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : > > // BEFORE LOOP >

...g0:ssub_1<def> = ... >> 48B = %vreg0 >> 64B = %vreg0:ssub_0 >> 80B %vreg0 = ... >> 96B = %vreg0:ssub_1 >> >> will be represented as the following live range(s): >> >> Common LiveRange: [16r,32r)[32r,64r),[80r,96r) >> SubRange with Mask 0x0004 (=ssub_0): [16r,64r)[80r,80d) >> SubRange with Mask 0x0008 (=ssub_1): [32r,48r)[80r,96r) >> >> Patches/Changes: >> * Moves live range management code in the LiveInterval class to a new >> class LiveRange...

...bb.3: >>>>>> NOOP implicit %1 >>>>>> >>>>>> >>>>>> >>>>>> $ llc -run-pass=liveintervals -debug-only=regalloc test.mir >>>>>> ********** INTERVALS ********** >>>>>> %0 [16r,64B:0)[112B,144r:0) 0 at 16r weight:0.000000e+00 >>>>>> %1 [80r,112B:1)[144r,176B:0)[176B,192r:2) 0 at 144r 1 at 80r 2 at 176B-phi weight:0.000000e+00 >>>>>> RegMasks: >>>>>> ********** MACHINEINSTRS ********** >>>>>> # Machi...