search for: 56r

...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 another old one). collectRanges for MI figures that it is moving a...

...t; 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 another old one). > collectRa...

...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 another old one). collectRanges for MI figures that it is moving a...

...xagon %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 another old one). > collectRanges...

...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 another old one). collectRanges for MI figures that it is moving a...

...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 another old o...

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

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

...t; 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 another old one). > collectRa...

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

...PIPE 0xcc08b240 16384 dovecot 5161 root 52r PIPE 0xcc08bbd0 16384 dovecot 5161 root 53r PIPE 0xcc08b750 16384 dovecot 5161 root 54r PIPE 0xcc08b900 16384 dovecot 5161 root 55r PIPE 0xcc08bb40 16384 dovecot 5161 root 56r PIPE 0xcccd5018 16384 dovecot 5161 root 57r PIPE 0xcc08b1b0 16384 dovecot 5161 root 58r PIPE 0xcccd5528 16384 dovecot 5161 root 59r PIPE 0xcccd52e8 16384 dovecot 5161 root 60r PIPE 0xcd659514 16384 dovecot 5161 root...

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking