search for: 368r

...ks 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> = LDriw <fi#-1>,...

...t 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>; I...

...ks 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...

...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 > 12...

...ks 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...

...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>...

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

...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 > &...

...t 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>; I...

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) {

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,

...kill>; R600_Reg128:%vreg1 R600_TReg32:%vreg17 register: %vreg1 replace range with [336r,352r:1) RESULT: [336r,352r:1)[352r,832r:0)[880B,1168B:0)  0 at 352r 1 at 336r 368B%vreg13<def> = MOV 1, 0, 0, 0, %ALU_LITERAL_X, 0, 0, 0, 1, pred:%PRED_SEL_OFF, 0; R600_Reg32:%vreg13 register: %vreg13 +[368r,432r:0) 384B%vreg0<def> = COPY %C0_X; R600_Reg32:%vreg0 register: %vreg0 +[384r,448B:0) +[448B,592B:0) +[880B,1168B:0) 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2 register: %vreg47 +[400r,448B:0) phi-join +[448B,464r:1) 416B%vreg48<def> = COPY %vreg3<k...

...; R600_TReg32:%vreg17 > register: %vreg1 replace range with [336r,352r:1) RESULT: > [336r,352r:1)[352r,832r:0)[880B,1168B:0)  0 at 352r 1 at 336r > 368B%vreg13<def> = MOV 1, 0, 0, 0, %ALU_LITERAL_X, 0, 0, 0, 1, > pred:%PRED_SEL_OFF, 0; R600_Reg32:%vreg13 > register: %vreg13 +[368r,432r:0) > 384B%vreg0<def> = COPY %C0_X; R600_Reg32:%vreg0 > register: %vreg0 +[384r,448B:0) +[448B,592B:0) +[880B,1168B:0) > 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2 > register: %vreg47 +[400r,448B:0) phi-join +[448B,464r:1) > 416B%vreg48<d...

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 >

..._Z<imp-use,kill>, %T2_Y<imp-use,kill>, %T2_X<imp-use,kill> # End machine code for function main. ********** COMPUTING LIVE INTERVALS ********** ********** Function: main BB#0:# derived from  16B%vreg3<def> = COPY %T1_X<kill>; R600_TReg32:%vreg3 register: %vreg3 +[16r,368r:0) 32B%vreg2<def> = COPY %T1_Y<kill>; R600_TReg32:%vreg2 register: %vreg2 +[32r,384r:0) 48B%vreg1<def> = COPY %T1_Z<kill>; R600_TReg32:%vreg1 register: %vreg1 +[48r,400r:0) 64B%vreg0<def> = COPY %T1_W<kill>; R600_TReg32:%vreg0 register: %vreg0 +[64r,416r:0) 80B%v...

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