search for: 32r

...* Function: caller > ********** JOINING INTERVALS *********** > entry: > 64B %RDI<def> = COPY %vreg0; GR64:%vreg0 > Considering merging %vreg0 with %RDI > Can only merge into reserved registers. > Remat: %RDI<def> = MOV64ri 12345123400 > Shrink: [32r,64r:0) 0 at 32r > Shrunk: [32r,48r:0) 0 at 32r > Trying to inflate 0 regs. > ********** INTERVALS ********** > %vreg0 = [32r,48r:0) 0 at 32r > RegMasks: 80r > > Jakob, what does "can only merge into reserved registers" mean in this instance. I don't see any re...

...TER COALESCING ********** ********** Function: caller ********** JOINING INTERVALS *********** entry: 64B %RDI<def> = COPY %vreg0; GR64:%vreg0 Considering merging %vreg0 with %RDI Can only merge into reserved registers. Remat: %RDI<def> = MOV64ri 12345123400 Shrink: [32r,64r:0) 0 at 32r Shrunk: [32r,48r:0) 0 at 32r Trying to inflate 0 regs. ********** INTERVALS ********** %vreg0 = [32r,48r:0) 0 at 32r RegMasks: 80r Jakob, what does "can only merge into reserved registers" mean in this instance. I don't see any reason for it not to do the merge....

On Aug 5, 2013, at 8:34 AM, Maurice Marks <maurice.marks at gmail.com> wrote: > Are you sure that's it? I commented that block out, rebuilt llvm 3.3, and it still duplicates the constant. > My concern is that long constant loads increase code size and if they can be avoided by better targeting it would be a win. My project's application of llvm tends to use a lot of long

...ion, 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_32 = V_MOV_...

...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,96r:0) 80B%vreg18<def> = COPY %C1_X; R600_Reg32:%vreg18 register: %vreg18 +[80r,128r:0) 96B%v...

...OMPUTING 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,96r:0) > 80B%vreg18<def> = COPY %C1_X; R600_Reg32:%vreg18 > registe...

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,

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

...ion, 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_32 = V_MOV_...

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

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

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

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

...part -------------- PreferIndirect: 1 PreferIndirect: 1 PreferIndirect: 1 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: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...

Older targets like Mips had/have assemblers and ABIs that carry a lot of baggage. The small bit of baggage that is giving me fits is that MipsELFObjectWriter needs to know the relocation model (static,pic,cpic), whether we are using xgot (-mgot), which abi (old,new), which architecture (32r[123],64[123]), which if any coprocessor or extention instructions are used (mips16,micromips,etc.). I shouldn't have to muck with base classes to handle esoteric target specific issues such as these. <target>ELFObjectWriteris used for direct object output whether directly from the codeg...

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

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

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

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

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