Arnold Schwaighofer
2012-Aug-30 19:43 UTC
[LLVMdev] MC Register mapping question (MCRegUnitIterator )
Hi Sergei, Register units != sub registers. Register units are an abstraction to describe overlapping of registers effectively. You probably wanted to use MCSubRegIterator. On Thu, Aug 30, 2012 at 2:30 PM, Sergei Larin <slarin at codeaurora.org> wrote:> Hello Jakob and everyone, > > I am observing an issue with MCRegUnitIterator in my back end, and trying > to reverse engineer some of the table gen magic around it, but if you or > someone readily knows the answer, I would highly appreciate it. > > Here is the problem. > > In my back end we have a rather simple int register file structure: > > // Integer registers. > def R0 : Ri< 0, "r0">, DwarfRegNum<[0]>; > def R1 : Ri< 1, "r1">, DwarfRegNum<[1]>; > def R2 : Ri< 2, "r2">, DwarfRegNum<[2]>; > def R3 : Ri< 3, "r3">, DwarfRegNum<[3]>; > ... > > ...which could be accessed as double regs in pairs: > > // Aliases of the R* registers used to hold 64-bit int values (doubles). > let SubRegIndices = [subreg_loreg, subreg_hireg] in { > def D0 : Rd< 0, "r1:0", [R0, R1]>, DwarfRegNum<[32]>; > def D1 : Rd< 2, "r3:2", [R2, R3]>, DwarfRegNum<[34]>; > def D2 : Rd< 4, "r5:4", [R4, R5]>, DwarfRegNum<[36]>; > > So R2:R3 are subregs of D1. > > These definitions are mapped to HexagonGenRegisterInfo.inc in something like > this: > enum { > NoRegister, > D0 = 1, > D1 = 2, > D2 = 3, > D3 = 4, > D4 = 5, > ... > R0 = 27, > R1 = 28, > R2 = 29, > R3 = 30, > R4 = 31, > ... > NUM_TARGET_REGS // 62 > }; > > On the other end of the problem, I use the following to iterate over > sub-regs of (in this case) D1: > > for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) { > DEBUG(dbgs() << "\tUnit (" << *Units << ")\n"); > ... > } > > For Reg==2==D1 I expect to see *Units to be 29==R2 and 30==R3 (its subregs). > Instead I see it to take values of 2==D1 and 3==D2! > > Moreover, if I iterate over units of an ordinary register, let's say > Reg==29==R2, *Units above iterates once with value of 2==D1! > > Either I do not understand how MCRegUnitIterator should work, or (more > likely) I have a problem in lib/Target/Hexagon/HexagonRegisterInfo.td, > because it seems that in HexagonGenRegisterInfo.inc I got something that > confuses tables to iterate over for subregs... > > So, if you know what it might be, please let me know. Thanks a lot. > > Sergei Larin > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by > The Linux Foundation > > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Sergei Larin >> Sent: Tuesday, August 28, 2012 4:34 PM >> To: 'Andrew Trick' >> Cc: 'LLVM Developers Mailing List' >> Subject: Re: [LLVMdev] Assert in LiveInterval update >> >> Andy, Lang, >> >> Thanks 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>, 0; >> mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 >> 20B %vreg31<def> = LDriw <fi#-2>, 0; mem:LD4[FixedStack-2] >> IntRegs:%vreg31 >> 24B %vreg26<def> = COPY %R0<kill>; IntRegs:%vreg26 >> 28B %vreg106<def> = TFRI 16777216; >> IntRegs:%vreg106<<<<<<<<<<<<<<<<<<<<<<<<<<< CurrentTop >> 32B %vreg29<def> = COPY %D2<kill>; DoubleRegs:%vreg29 >> 48B %vreg28<def> = COPY %D1<kill>; DoubleRegs:%vreg28 >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Needs 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 another old one). >> collectRanges for MI figures that it is moving a paired register, and >> correctly(?) selects these two ranges to update for %R2:R3 >> >> [0B,56r:0)[368r,416r:5)... >> [0B,56r:0)[352r,416r:5)... >> >> ___BUT____ after the update, my new ranges look like this: >> >> R2 = [0B,32r:0)[352r,416r:5)... >> R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have >> become 48r >> R4 = [0B,48r:0)[384r,416r:4)... >> R5 = [0B,48r:0)[400r,416r:4)... >> .... >> 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<def> = LDriw <fi#-2>, 0; mem:LD4[FixedStack-2] >> IntRegs:%vreg31 >> 24B %vreg26<def> = COPY %R0<kill>; IntRegs:%vreg26 >> 32B %vreg28<def> = COPY %D1<kill>; DoubleRegs:%vreg28 >> <<<<<<<<<<<<<<<< Moved instruction >> 40B %vreg106<def> = TFRI 16777216; IntRegs:%vreg106 >> 48B %vreg29<def> = COPY %D2<kill>; DoubleRegs:%vreg29 >> 96B %vreg37<def> = LDriw <fi#-8>, 0; mem:LD4[FixedStack-8] >> IntRegs:%vreg37 >> >> This is not caught at this time, and only much later, when another >> instruction is scheduled to __the same slot___ the old one "occupied" >> (48B), the discrepancy is caught by one of unrelated asserts... I think >> at that time there are simply some stale aliases in liveness table. >> >> I'm going to continue with this tomorrow, but if this helps to identify >> a lurking bug today, my day was worth it :) :) :) >> >> Sergei >> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. >> >> >> > -----Original Message----- >> > From: Andrew Trick [mailto:atrick at apple.com] >> > Sent: Tuesday, August 28, 2012 3:47 PM >> > To: Sergei Larin >> > Cc: LLVM Developers Mailing List; Lang Hames >> > Subject: Re: [LLVMdev] Assert in LiveInterval update >> > >> > 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 location in the instruction >> > stream. >> > > MachineInstr *MI = SU->getInstr(); >> > > >> > > if (IsTopNode) { >> > > assert(SU->isTopReady() && "node still has unscheduled >> > dependencies"); >> > > if (&*CurrentTop == MI) <<<<<<<<<<<<<<<<<< Here >> we >> > make >> > > sure that CurrentTop != MI. >> > > CurrentTop = nextIfDebug(++CurrentTop, CurrentBottom); >> > > else { >> > > moveInstruction(MI, CurrentTop); >> > > TopRPTracker.setPos(MI); >> > > } >> > > ... >> > > >> > > But in moveInstruction we use >> > > >> > > // Update the instruction stream. >> > > BB->splice(InsertPos, BB, MI); >> > > >> > > And splice as far as I understand moves MI to the location right >> > > __before__ InsertPos. Our previous check made sure that InsertPos >> !>> > > MI, But I do hit a case, when MI == InsertPos--, and effectively >> > tries >> > > to swap instruction with itself... which make live update mechanism >> > very unhappy. >> > > >> > > If I am missing something in intended logic, please explain, >> > otherwise >> > > it looks like we need to adjust that check to make sure we never >> > > even considering this situation (swapping with self). >> > > >> > > I also wonder if we want explicit check in live update with more >> > > meaningful assert :) >> > >> > Thanks for debugging this! The code above assumes that you're moving >> > an unscheduled instruction, which should never be above InsertPos for >> > top- down scheduling. If the instruction was in multiple ready Q's, >> > then you may attempt to schedule it multiple times. You can avoid >> this >> > by checking Su->isScheduled in your Strategy's pickNode. See >> > InstructionShuffler::pickNode for an example. I don't see an >> > equivalent check in ConvergingScheduler, but there probably should >> be. >> > >> > Another possibility to consider is something strange with >> DebugValues, >> > which I haven't tested much. >> > >> > I reproduced the same assert on arm and filed PR13719. I'm not sure >> > yet if it's exactly the same issue, but we can move the discussion >> there. >> > >> > We need a better assert in live update and probably the scheduler >> too. >> > Lang mentioned he may look at the issue today. Meanwhile, I hope my >> > suggestion above helps. >> > >> > -Andy >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Sergei Larin
2012-Aug-30 20:01 UTC
[LLVMdev] MC Register mapping question (MCRegUnitIterator )
Arnold, It is not my code per say - this is what is done in LiveIntervalAnalysis.cpp collectRanges(), it wants to iterate over "units" of D1 (whatever they are assumed to be), but right there it associates them with actual physical register live ranges (see the tread below), and it does it wrongly. I was trying to pinpoint exactly to where the issue is, but there are too many interdependent links in this chain, so I am seeking some domain knowledge :) Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation> -----Original Message----- > From: Arnold Schwaighofer [mailto:arnolds at codeaurora.org] > Sent: Thursday, August 30, 2012 2:43 PM > To: Sergei Larin > Cc: Jakob Olesen; LLVM Developers Mailing List > Subject: Re: [LLVMdev] MC Register mapping question (MCRegUnitIterator > ) > > Hi Sergei, > > Register units != sub registers. > > Register units are an abstraction to describe overlapping of registers > effectively. > > You probably wanted to use MCSubRegIterator. > > > On Thu, Aug 30, 2012 at 2:30 PM, Sergei Larin <slarin at codeaurora.org> > wrote: > > Hello Jakob and everyone, > > > > I am observing an issue with MCRegUnitIterator in my back end, and > > trying to reverse engineer some of the table gen magic around it, but > > if you or someone readily knows the answer, I would highly appreciate > it. > > > > Here is the problem. > > > > In my back end we have a rather simple int register file structure: > > > > // Integer registers. > > def R0 : Ri< 0, "r0">, DwarfRegNum<[0]>; > > def R1 : Ri< 1, "r1">, DwarfRegNum<[1]>; > > def R2 : Ri< 2, "r2">, DwarfRegNum<[2]>; > > def R3 : Ri< 3, "r3">, DwarfRegNum<[3]>; ... > > > > ...which could be accessed as double regs in pairs: > > > > // Aliases of the R* registers used to hold 64-bit int values > (doubles). > > let SubRegIndices = [subreg_loreg, subreg_hireg] in { > > def D0 : Rd< 0, "r1:0", [R0, R1]>, DwarfRegNum<[32]>; > > def D1 : Rd< 2, "r3:2", [R2, R3]>, DwarfRegNum<[34]>; > > def D2 : Rd< 4, "r5:4", [R4, R5]>, DwarfRegNum<[36]>; > > > > So R2:R3 are subregs of D1. > > > > These definitions are mapped to HexagonGenRegisterInfo.inc in > > something like > > this: > > enum { > > NoRegister, > > D0 = 1, > > D1 = 2, > > D2 = 3, > > D3 = 4, > > D4 = 5, > > ... > > R0 = 27, > > R1 = 28, > > R2 = 29, > > R3 = 30, > > R4 = 31, > > ... > > NUM_TARGET_REGS // 62 > > }; > > > > On the other end of the problem, I use the following to iterate over > > sub-regs of (in this case) D1: > > > > for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) { > > DEBUG(dbgs() << "\tUnit (" << *Units << ")\n"); ... > > } > > > > For Reg==2==D1 I expect to see *Units to be 29==R2 and 30==R3 (its > subregs). > > Instead I see it to take values of 2==D1 and 3==D2! > > > > Moreover, if I iterate over units of an ordinary register, let's say > > Reg==29==R2, *Units above iterates once with value of 2==D1! > > > > Either I do not understand how MCRegUnitIterator should work, or > (more > > likely) I have a problem in > lib/Target/Hexagon/HexagonRegisterInfo.td, > > because it seems that in HexagonGenRegisterInfo.inc I got something > > that confuses tables to iterate over for subregs... > > > > So, if you know what it might be, please let me know. Thanks a lot. > > > > Sergei Larin > > > > > > -- > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > > hosted by The Linux Foundation > > > > > >> -----Original Message----- > >> From: llvmdev-bounces at cs.uiuc.edu > >> [mailto:llvmdev-bounces at cs.uiuc.edu] > >> On Behalf Of Sergei Larin > >> Sent: Tuesday, August 28, 2012 4:34 PM > >> To: 'Andrew Trick' > >> Cc: 'LLVM Developers Mailing List' > >> Subject: Re: [LLVMdev] Assert in LiveInterval update > >> > >> Andy, Lang, > >> > >> Thanks 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>, 0; > >> mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 > >> 20B %vreg31<def> = LDriw <fi#-2>, 0; mem:LD4[FixedStack-2] > >> IntRegs:%vreg31 > >> 24B %vreg26<def> = COPY %R0<kill>; IntRegs:%vreg26 > >> 28B %vreg106<def> = TFRI 16777216; > >> IntRegs:%vreg106<<<<<<<<<<<<<<<<<<<<<<<<<<< CurrentTop > >> 32B %vreg29<def> = COPY %D2<kill>; DoubleRegs:%vreg29 > >> 48B %vreg28<def> = COPY %D1<kill>; DoubleRegs:%vreg28 > >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Needs 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 another old one). > >> collectRanges for MI figures that it is moving a paired register, > and > >> correctly(?) selects these two ranges to update for %R2:R3 > >> > >> [0B,56r:0)[368r,416r:5)... > >> [0B,56r:0)[352r,416r:5)... > >> > >> ___BUT____ after the update, my new ranges look like this: > >> > >> R2 = [0B,32r:0)[352r,416r:5)... > >> R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have > >> become 48r > >> R4 = [0B,48r:0)[384r,416r:4)... > >> R5 = [0B,48r:0)[400r,416r:4)... > >> .... > >> 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<def> = LDriw <fi#-2>, 0; mem:LD4[FixedStack-2] > >> IntRegs:%vreg31 > >> 24B %vreg26<def> = COPY %R0<kill>; IntRegs:%vreg26 > >> 32B %vreg28<def> = COPY %D1<kill>; DoubleRegs:%vreg28 > >> <<<<<<<<<<<<<<<< Moved instruction > >> 40B %vreg106<def> = TFRI 16777216; IntRegs:%vreg106 > >> 48B %vreg29<def> = COPY %D2<kill>; DoubleRegs:%vreg29 > >> 96B %vreg37<def> = LDriw <fi#-8>, 0; mem:LD4[FixedStack-8] > >> IntRegs:%vreg37 > >> > >> This is not caught at this time, and only much later, when another > >> instruction is scheduled to __the same slot___ the old one > "occupied" > >> (48B), the discrepancy is caught by one of unrelated asserts... I > >> think at that time there are simply some stale aliases in liveness > table. > >> > >> I'm going to continue with this tomorrow, but if this helps to > >> identify a lurking bug today, my day was worth it :) :) :) > >> > >> Sergei > >> > >> -- > >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > >> > >> > >> > -----Original Message----- > >> > From: Andrew Trick [mailto:atrick at apple.com] > >> > Sent: Tuesday, August 28, 2012 3:47 PM > >> > To: Sergei Larin > >> > Cc: LLVM Developers Mailing List; Lang Hames > >> > Subject: Re: [LLVMdev] Assert in LiveInterval update > >> > > >> > 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 location in the > instruction > >> > stream. > >> > > MachineInstr *MI = SU->getInstr(); > >> > > > >> > > if (IsTopNode) { > >> > > assert(SU->isTopReady() && "node still has unscheduled > >> > dependencies"); > >> > > if (&*CurrentTop == MI) <<<<<<<<<<<<<<<<<< > Here > >> we > >> > make > >> > > sure that CurrentTop != MI. > >> > > CurrentTop = nextIfDebug(++CurrentTop, CurrentBottom); > >> > > else { > >> > > moveInstruction(MI, CurrentTop); > >> > > TopRPTracker.setPos(MI); > >> > > } > >> > > ... > >> > > > >> > > But in moveInstruction we use > >> > > > >> > > // Update the instruction stream. > >> > > BB->splice(InsertPos, BB, MI); > >> > > > >> > > And splice as far as I understand moves MI to the location right > >> > > __before__ InsertPos. Our previous check made sure that > InsertPos > >> !> >> > > MI, But I do hit a case, when MI == InsertPos--, and effectively > >> > tries > >> > > to swap instruction with itself... which make live update > >> > > mechanism > >> > very unhappy. > >> > > > >> > > If I am missing something in intended logic, please explain, > >> > otherwise > >> > > it looks like we need to adjust that check to make sure we never > >> > > even considering this situation (swapping with self). > >> > > > >> > > I also wonder if we want explicit check in live update with more > >> > > meaningful assert :) > >> > > >> > Thanks for debugging this! The code above assumes that you're > >> > moving an unscheduled instruction, which should never be above > >> > InsertPos for > >> > top- down scheduling. If the instruction was in multiple ready > Q's, > >> > then you may attempt to schedule it multiple times. You can avoid > >> this > >> > by checking Su->isScheduled in your Strategy's pickNode. See > >> > InstructionShuffler::pickNode for an example. I don't see an > >> > equivalent check in ConvergingScheduler, but there probably should > >> be. > >> > > >> > Another possibility to consider is something strange with > >> DebugValues, > >> > which I haven't tested much. > >> > > >> > I reproduced the same assert on arm and filed PR13719. I'm not > sure > >> > yet if it's exactly the same issue, but we can move the discussion > >> there. > >> > > >> > We need a better assert in live update and probably the scheduler > >> too. > >> > Lang mentioned he may look at the issue today. Meanwhile, I hope > my > >> > suggestion above helps. > >> > > >> > -Andy > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Arnold Schwaighofer
2012-Aug-30 20:20 UTC
[LLVMdev] MC Register mapping question (MCRegUnitIterator )
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))
collectRanges(MO, LI, Entering, Internal, Exiting, OldIdx);
} else {
// Collect ranges for individual virtual registers.
collectRanges(MO, &LIS.getInterval(Reg),
Entering, Internal, Exiting, OldIdx);
}
As an experiment, you could replace getCachedRegUnit with getRegUnit
(the uncached version) to make verify we don't have a stale state in
the cache.
On Thu, Aug 30, 2012 at 3:01 PM, Sergei Larin <slarin at codeaurora.org>
wrote:> Arnold,
>
> It is not my code per say - this is what is done in
> LiveIntervalAnalysis.cpp collectRanges(), it wants to iterate over
"units"
> of D1 (whatever they are assumed to be), but right there it associates them
> with actual physical register live ranges (see the tread below), and it
does
> it wrongly. I was trying to pinpoint exactly to where the issue is, but
> there are too many interdependent links in this chain, so I am seeking
some
> domain knowledge :)