search for: 400r

...vreg18<def> = COPY %C1_X; R600_Reg32:%vreg18 register: %vreg18 +[80r,128r:0) 96B%vreg19:sel_x<def,read-undef> = COPY %vreg14<kill>; R600_Reg128:%vreg19 R600_TReg32:%vreg14 register: %vreg19 +[96r,144r:0) 112B%vreg2<def> = COPY %C1_Y; R600_Reg32:%vreg2 register: %vreg2 +[112r,400r:0) 128B%vreg21:sel_x<def,read-undef> = COPY %vreg18<kill>; R600_Reg128:%vreg21 R600_Reg32:%vreg18 register: %vreg21 +[128r,176r:0) 144B%vreg23<def> = COPY %vreg19<kill>; R600_Reg128:%vreg23,%vreg19 register: %vreg23 +[144r,224r:0) 160B%vreg23:sel_y<def> = COPY %vreg15&...

...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>, 0; mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 20B %vreg31&l...

...R600_Reg32:%vreg18 > register: %vreg18 +[80r,128r:0) > 96B%vreg19:sel_x<def,read-undef> = COPY %vreg14<kill>; > R600_Reg128:%vreg19 R600_TReg32:%vreg14 > register: %vreg19 +[96r,144r:0) > 112B%vreg2<def> = COPY %C1_Y; R600_Reg32:%vreg2 > register: %vreg2 +[112r,400r:0) > 128B%vreg21:sel_x<def,read-undef> = COPY %vreg18<kill>; > R600_Reg128:%vreg21 R600_Reg32:%vreg18 > register: %vreg21 +[128r,176r:0) > 144B%vreg23<def> = COPY %vreg19<kill>; R600_Reg128:%vreg23,%vreg19 > register: %vreg23 +[144r,224r:0) > 160B%vreg23:s...

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

...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>, 0; mem:LD4[FixedStack-1](alig...

...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>, 0; > mem:LD4[FixedStack-1]...

...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>, 0; mem:LD4[FixedStack-1](alig...

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

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,

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

...352B    %vreg20:sel_x<def,undef> = COPY %vreg16<kill>[TF=2], %vreg20<imp-def>; R600_Reg128:%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...

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

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

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

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

...----- Computing live-in reg-units in ABI blocks. 0B %bb.0 R0#0 R1#0 R2#0 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 w...

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 >

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

...:# 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%vreg4<def> = MOV 1, 0, 0, 0, %vreg3, 1, 0, 0, 1, pred:%PRED_SEL_OFF, 0; R600_Reg32:%vreg4 R600_TReg32:%vreg3 register: %vreg4 +[80r,112r:0) 96B%vreg5<def> = MOV 1, 0, 0, 0, %ALU_LITER...