search for: 56b

...to move above 28B 96B %vreg37<def> = LDriw <fi#-8>, 0; mem:LD4[FixedStack-8] IntRegs:%vreg37 In Hexagon %D1==%R0:R1 (double reg), %D2==%R2:R3 etc. The MI move triggers liveness update, which first triggers SlotIndex renumbering: *** Renumbered SlotIndexes 24-56 *** So my 48B becomes 56B, so after the update new live ranges look like this: R2 = [0B,56r:0)[352r,416r:5)... R3 = [0B,56r:0)[368r,416r:5)... R4 = [0B,48r:0)[384r,416r:4)... R5 = [0B,48r:0)[400r,416r:4)... Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also new after renumbering. But happens to match...

...] 36B %vreg44<def> = LDImm 1103515245; REG1:%vreg44 dbg:path/to/source:9:34 @[ path/to/source:25:13 ] 44B %vreg143:vsub32_1<def,read-undef> = LDImm 0; REG2:%vreg143 48B %vreg68<def> = LDImm 12345; REG1:%vreg68 dbg:path/to/source:9:47 @[ path/to/source:25:13 ] 56B %vreg143:vsub32_0<def> = COPY %vreg143:vsub32_1; REG2:%vreg143 60B %vreg78<def> = LDImm 32; REG1:%vreg78 This change seems to affect the weight assigned to the LiveIntervals for each virtual register which in turn changes the allocation order. It would be my expectation...

...= LDriw <fi#-8>, 0; mem:LD4[FixedStack-8] > IntRegs:%vreg37 > > In Hexagon %D1==%R0:R1 (double reg), %D2==%R2:R3 etc. > The MI move triggers liveness update, which first triggers SlotIndex > renumbering: > > *** Renumbered SlotIndexes 24-56 *** > > So my 48B becomes 56B, so after the update new live ranges look like this: > > R2 = [0B,56r:0)[352r,416r:5)... > R3 = [0B,56r:0)[368r,416r:5)... > R4 = [0B,48r:0)[384r,416r:4)... > R5 = [0B,48r:0)[400r,416r:4)... > > Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also > new &...

...ve 28B 96B %vreg37<def> = LDriw <fi#-8>, 0; mem:LD4[FixedStack-8] IntRegs:%vreg37 In Hexagon %D1==%R0:R1 (double reg), %D2==%R2:R3 etc. The MI move triggers liveness update, which first triggers SlotIndex renumbering: *** Renumbered SlotIndexes 24-56 *** So my 48B becomes 56B, so after the update new live ranges look like this: R2 = [0B,56r:0)[352r,416r:5)... R3 = [0B,56r:0)[368r,416r:5)... R4 = [0B,48r:0)[384r,416r:4)... R5 = [0B,48r:0)[400r,416r:4)... Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also new after renumbering. But happens to match...

...vreg44<def> = LDImm 1103515245; REG1:%vreg44 dbg:path/to/source:9:34 @[ path/to/source:25:13 ] > 44B %vreg143:vsub32_1<def,read-undef> = LDImm 0; REG2:%vreg143 > 48B %vreg68<def> = LDImm 12345; REG1:%vreg68 dbg:path/to/source:9:47 @[ path/to/source:25:13 ] > 56B %vreg143:vsub32_0<def> = COPY %vreg143:vsub32_1; REG2:%vreg143 > 60B %vreg78<def> = LDImm 32; REG1:%vreg78 > > This change seems to affect the weight assigned to the LiveIntervals for each virtual register which in turn changes the allocation order. > > It...

...Driw <fi#-8>, 0; mem:LD4[FixedStack-8] > IntRegs:%vreg37 > > In Hexagon %D1==%R0:R1 (double reg), %D2==%R2:R3 etc. > The MI move triggers liveness update, which first triggers SlotIndex > renumbering: > > *** Renumbered SlotIndexes 24-56 *** > > So my 48B becomes 56B, so after the update new live ranges look like > this: > > R2 = [0B,56r:0)[352r,416r:5)... > R3 = [0B,56r:0)[368r,416r:5)... > R4 = [0B,48r:0)[384r,416r:4)... > R5 = [0B,48r:0)[400r,416r:4)... > > Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B > (als...

...vreg44<def> = LDImm 1103515245; REG1:%vreg44 dbg:path/to/source:9:34 @[ path/to/source:25:13 ] > 44B %vreg143:vsub32_1<def,read-undef> = LDImm 0; REG2:%vreg143 > 48B %vreg68<def> = LDImm 12345; REG1:%vreg68 dbg:path/to/source:9:47 @[ path/to/source:25:13 ] > 56B %vreg143:vsub32_0<def> = COPY %vreg143:vsub32_1; REG2:%vreg143 > 60B %vreg78<def> = LDImm 32; REG1:%vreg78 > > This change seems to affect the weight assigned to the LiveIntervals for each virtual register which in turn changes the allocation order. > > It...

...ve 28B 96B %vreg37<def> = LDriw <fi#-8>, 0; mem:LD4[FixedStack-8] IntRegs:%vreg37 In Hexagon %D1==%R0:R1 (double reg), %D2==%R2:R3 etc. The MI move triggers liveness update, which first triggers SlotIndex renumbering: *** Renumbered SlotIndexes 24-56 *** So my 48B becomes 56B, so after the update new live ranges look like this: R2 = [0B,56r:0)[352r,416r:5)... R3 = [0B,56r:0)[368r,416r:5)... R4 = [0B,48r:0)[384r,416r:4)... R5 = [0B,48r:0)[400r,416r:4)... Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also new after renumbering. But happens to match...

...xedStack-8] >> IntRegs:%vreg37 >> >> In Hexagon %D1==%R0:R1 (double reg), %D2==%R2:R3 etc. >> The MI move triggers liveness update, which first triggers SlotIndex >> renumbering: >> >> *** Renumbered SlotIndexes 24-56 *** >> >> So my 48B becomes 56B, so after the update new live ranges look like >> this: >> >> R2 = [0B,56r:0)[352r,416r:5)... >> R3 = [0B,56r:0)[368r,416r:5)... >> R4 = [0B,48r:0)[384r,416r:4)... >> R5 = [0B,48r:0)[400r,416r:4)... >> >> Then in LiveIntervals::handleMove OldIndex 56B...

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

...; >> > >> In Hexagon %D1==%R0:R1 (double reg), %D2==%R2:R3 etc. > >> The MI move triggers liveness update, which first triggers SlotIndex > >> renumbering: > >> > >> *** Renumbered SlotIndexes 24-56 *** > >> > >> So my 48B becomes 56B, so after the update new live ranges look like > >> this: > >> > >> R2 = [0B,56r:0)[352r,416r:5)... > >> R3 = [0B,56r:0)[368r,416r:5)... > >> R4 = [0B,48r:0)[384r,416r:4)... > >> R5 = [0B,48r:0)[400r,416r:4)... > >> > >> Then i...

...= LDriw <fi#-8>, 0; mem:LD4[FixedStack-8] > IntRegs:%vreg37 > > In Hexagon %D1==%R0:R1 (double reg), %D2==%R2:R3 etc. > The MI move triggers liveness update, which first triggers SlotIndex > renumbering: > > *** Renumbered SlotIndexes 24-56 *** > > So my 48B becomes 56B, so after the update new live ranges look like this: > > R2 = [0B,56r:0)[352r,416r:5)... > R3 = [0B,56r:0)[368r,416r:5)... > R4 = [0B,48r:0)[384r,416r:4)... > R5 = [0B,48r:0)[400r,416r:4)... > > Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also > new &...

...A NA NA NA ... $ 50B: num NA NA NA NA NA NA NA NA NA NA ... $ 52A: num NA NA NA NA NA NA NA NA NA NA ... $ 52B: num NA NA NA NA NA NA NA NA NA NA ... $ 55A: num NA NA NA NA NA NA NA NA NA NA ... $ 55B: num NA NA NA NA NA NA NA NA NA NA ... $ 56A: num NA NA NA NA NA NA NA NA NA NA ... $ 56B: num NA NA NA NA NA NA NA NA NA NA ... $ 59A: num NA NA NA NA NA NA NA NA NA NA ... $ 59B: num NA NA NA NA NA NA NA NA NA NA ... $ 40A: num NA NA NA NA 2.93 3.38 3.19 3.62 2.55 1.69 ... $ 40B: num NA NA NA NA NA NA NA NA NA NA ... $ 39A: num NA NA NA NA NA NA NA NA NA NA ... $ 39B: num...

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,

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

...DW_TAG_const_type Tag = 19, Count = 72995, Ops = 583960, Name = DW_TAG_structure_type (Note: the InlinedLineTables stat is included in LineTables stat.) You can determine the rough memory footprint of each type of node by multiplying the "Count" by `sizeof(MDNode)` (x86-64: 56B) and the "Ops" by `sizeof(MDNodeOperand)` (x86-64: 32B). Overall, there are 7.5M linetables with 30M operands, so by this method their footprint is ~1.3GB. There are 7.6M descriptors with 42.4M operands, so their footprint is ~1.7GB. I dumped another stat periodically to tell me the pe...

...lt;__FUNCTION__.21945>: > 500: 6e outsb %ds:(%esi),(%dx) > 501: 6f outsl %ds:(%esi),(%dx) > 502: 6e outsb %ds:(%esi),(%dx) > 503: 6f outsl %ds:(%esi),(%dx) > - 504: 76 65 jbe 56b <__FUNCTION__.22734+0x2> > - 506: 72 6c jb 574 <__FUNCTION__.22734+0xb> > + 504: 76 65 jbe 56b <__FUNCTION__.22647+0x2> > + 506: 72 6c jb 574 <__FUNCTION__.22647+0xb> > 508: 61 popa &...

The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the

/I made an error, I swapped two diagrams, it should be this:/ Here's how I've been doing it: BUTT ===> WAN ===> Icecast server I thought I might try this instead: BUTT --> localhost Icecast server ===> WAN ===> Icecast server -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics On