search for: 416r

Andy, Lang, Thanks for the suggestion. I have spent more time with it today, and I do see some strange things in liveness update. I am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)... I schedule the following instruction (48B): 0B BB#0: derived from LLVM BB %entry Live Ins: %R0 %R1 %D1 %D2 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 12B %vreg30<def&...

...on. > > > I have spent more time with it today, and I do see some strange things in > liveness update. I am not at the actual cause yet, but here is what I got > so > far: > > I have the following live ranges when I start scheduling a region: > > R2 = [0B,48r:0)[352r,416r:5)... > R3 = [0B,48r:0)[368r,416r:5)... > R4 = [0B,32r:0)[384r,416r:4)... > R5 = [0B,32r:0)[400r,416r:4)... > > I schedule the following instruction (48B): > > 0B BB#0: derived from LLVM BB %entry > Live Ins: %R0 %R1 %D1 %D2 > 8B %vreg27<d...

...wrote: Andy, Lang, Thanks for the suggestion. I have spent more time with it today, and I do see some strange things in liveness update. I am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)... I schedule the following instruction (48B): 0B BB#0: derived from LLVM BB %entry Live Ins: %R0 %R1 %D1 %D2 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vre...

...> > > I have spent more time with it today, and I do see some strange > things in liveness update. I am not at the actual cause yet, but here > is what I got so > far: > > I have the following live ranges when I start scheduling a region: > > R2 = [0B,48r:0)[352r,416r:5)... > R3 = [0B,48r:0)[368r,416r:5)... > R4 = [0B,32r:0)[384r,416r:4)... > R5 = [0B,32r:0)[400r,416r:4)... > > I schedule the following instruction (48B): > > 0B BB#0: derived from LLVM BB %entry > Live Ins: %R0 %R1 %D1 %D2 > 8B %vreg27<def> = COPY %R1<k...

...wrote: Andy, Lang, Thanks for the suggestion. I have spent more time with it today, and I do see some strange things in liveness update. I am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)... I schedule the following instruction (48B): 0B BB#0: derived from LLVM BB %entry Live Ins: %R0 %R1 %D1 %D2 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vre...

...spent more time with it today, and I do see some strange >> things in liveness update. I am not at the actual cause yet, but here >> is what I got so >> far: >> >> I have the following live ranges when I start scheduling a region: >> >> R2 = [0B,48r:0)[352r,416r:5)... >> R3 = [0B,48r:0)[368r,416r:5)... >> R4 = [0B,32r:0)[384r,416r:4)... >> R5 = [0B,32r:0)[400r,416r:4)... >> >> I schedule the following instruction (48B): >> >> 0B BB#0: derived from LLVM BB %entry >> Live Ins: %R0 %R1 %D1 %D2 >&...

On Aug 28, 2012, at 8:18 AM, Sergei Larin <slarin at codeaurora.org> wrote: > > I've described that issue (see below) when you were out of town... I think > I am getting more context on it. Please take a look... > > So, in short, when the new MI scheduler performs move of an instruction, it > does something like this: > > // Move the instruction to its new

...see some strange > >> things in liveness update. I am not at the actual cause yet, but > here > >> is what I got so > >> far: > >> > >> I have the following live ranges when I start scheduling a region: > >> > >> R2 = [0B,48r:0)[352r,416r:5)... > >> R3 = [0B,48r:0)[368r,416r:5)... > >> R4 = [0B,32r:0)[384r,416r:4)... > >> R5 = [0B,32r:0)[400r,416r:4)... > >> > >> I schedule the following instruction (48B): > >> > >> 0B BB#0: derived from LLVM BB %entry > >>...

...on. > > > I have spent more time with it today, and I do see some strange things in > liveness update. I am not at the actual cause yet, but here is what I got > so > far: > > I have the following live ranges when I start scheduling a region: > > R2 = [0B,48r:0)[352r,416r:5)... > R3 = [0B,48r:0)[368r,416r:5)... > R4 = [0B,32r:0)[384r,416r:4)... > R5 = [0B,32r:0)[400r,416r:4)... > > I schedule the following instruction (48B): > > 0B BB#0: derived from LLVM BB %entry > Live Ins: %R0 %R1 %D1 %D2 > 8B %vreg27<d...

On Aug 30, 2012, at 1:20 PM, Arnold Schwaighofer <arnolds at codeaurora.org> wrote: > The code in collectRanges() does: > > // Collect ranges for register units. These live ranges are computed on > // demand, so just skip any that haven't been computed yet. > if (TargetRegisterInfo::isPhysicalRegister(Reg)) { > for (MCRegUnitIterator Units(Reg,

Andy, I've described that issue (see below) when you were out of town... I think I am getting more context on it. Please take a look... So, in short, when the new MI scheduler performs move of an instruction, it does something like this: // Move the instruction to its new location in the instruction stream. MachineInstr *MI = SU->getInstr(); if (IsTopNode) {

...25 register: %vreg27 replace range with [256r,272r:1) RESULT: [256r,272r:1)[272r,304r:0)  0 at 272r 1 at 256r 288B%vreg28<def> = COPY %C1_W; R600_Reg32:%vreg28 register: %vreg28 +[288r,320r:0) 304B%vreg3<def> = COPY %vreg27<kill>; R600_Reg128:%vreg3,%vreg27 register: %vreg3 +[304r,416r:0) 320B%vreg3:sel_w<def> = COPY %vreg28<kill>; R600_Reg128:%vreg3 R600_Reg32:%vreg28 register: %vreg3 replace range with [304r,320r:1) RESULT: [304r,320r:1)[320r,416r:0)  0 at 320r 1 at 304r 336B%vreg1<def> = COPY %vreg26<kill>; R600_Reg128:%vreg1,%vreg26 register: %vreg1 +[...

...ce range with [256r,272r:1) RESULT: > [256r,272r:1)[272r,304r:0)  0 at 272r 1 at 256r > 288B%vreg28<def> = COPY %C1_W; R600_Reg32:%vreg28 > register: %vreg28 +[288r,320r:0) > 304B%vreg3<def> = COPY %vreg27<kill>; R600_Reg128:%vreg3,%vreg27 > register: %vreg3 +[304r,416r:0) > 320B%vreg3:sel_w<def> = COPY %vreg28<kill>; R600_Reg128:%vreg3 > R600_Reg32:%vreg28 > register: %vreg3 replace range with [304r,320r:1) RESULT: > [304r,320r:1)[320r,416r:0)  0 at 320r 1 at 304r > 336B%vreg1<def> = COPY %vreg26<kill>; R600_Reg128:%vreg1,...

The code in collectRanges() does: // Collect ranges for register units. These live ranges are computed on // demand, so just skip any that haven't been computed yet. if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) if (LiveInterval *LI = LIS.getCachedRegUnit(*Units))

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 >

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

...********** 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 RegMasks: 144r 240r 336r 432r ********** MACHINEINSTRS...

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 ... Some COPYs.... 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2

Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. vreg10 only appears in BB#3, and the join only occurs in BB#3 apparently even if vreg32 lives in the 4 machine blocks After joining, there

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