similar to: [LLVMdev] Possible LiveInterval Bug

AFAIK std::upper_bound() would not return end(), right? Evan On Jan 29, 2008, at 3:08 PM, David Greene wrote: > I just ran into a problem here. I'm in SimpleRegisterCoalescing at > the point > where EXTRACT_SUBREG coalescing updates live ranges of aliased > registers (around line 473 of SimpleRegisterCoalescing.cpp). > > There's a call to MergeValueInAsValue at line

Hrm, I see a bug here. Let's say the liverange in question is [13,20) and the interval it's being merged to is something like this: [1, 4), [10, 15) IP = std::upper_bound(IP, end(), Start); if (IP != begin() && IP[-1].end > Start) { if (IP->valno != LHSValNo) { ReplacedValNos.push_back(IP->valno); IP->valno = LHSValNo; //

On Wednesday 30 January 2008 15:06, Evan Cheng wrote: > Hrm, I see a bug here. Let's say the liverange in question is [13,20) > and the interval it's being merged to is something like this: [1, 4), > [10, 15) > > IP = std::upper_bound(IP, end(), Start); > if (IP != begin() && IP[-1].end > Start) { > if (IP->valno != LHSValNo) { >

On Wednesday 30 January 2008 02:02, Evan Cheng wrote: > AFAIK std::upper_bound() would not return end(), right? Yes, it can return end(). In fact that's exactly what I'm seeing. std::upper_bound is just binary search and returns where the element should be inserted to retain ordering. So for example, if my iterator range is over: 1 2 3 4 5 and I call std::upper_bound(begin(),

On Jan 30, 2008, at 1:21 PM, David Greene wrote: > On Wednesday 30 January 2008 15:06, Evan Cheng wrote: >> Hrm, I see a bug here. Let's say the liverange in question is [13,20) >> and the interval it's being merged to is something like this: [1, 4), >> [10, 15) >> >> IP = std::upper_bound(IP, end(), Start); >> if (IP != begin() &&

On Thursday 17 January 2008 13:03, Evan Cheng wrote: > > So why does the live range extend throughout the entire basic block? > > > > %reg1055 doesn't appear anywhere else in the program so it shouldn't > > be > > live-in to the block. > > It could be a bug. Can you get me a test case? I'll see if I can whittle it down. It's a pretty huge

On Jan 16, 2008, at 11:49 AM, David Greene wrote: > I had been assuming that give a LiveRange a, a.valno->def, if > valid, would be the same as a.start. But this is apparently not > always the case. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill>

Hi Jonas, Thanks for your patience. After spending some time looking at the additional output you gave me, I agree that your fix is the right one. I was worried that this problem may arise because we were spilling not real user, but in fact what I thought was the problem is an optimization we could do :). See my comments inlined for a few nitpicks before you commit. Thanks again, -Quentin On

I had been assuming that give a LiveRange a, a.valno->def, if valid, would be the same as a.start. But this is apparently not always the case. For example: Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr

Post-phi-elimination, when can a LiveInterval VNInfo have a ~1 or ~0 def value? I've seen ~0 on intervals created for spills. Can it happen anywhere else? -Dave

Hi all, I'm tracking down a register allocation problem and I'm trying to understand this piece of code in InlineSpiller::spillAroundUses: // Find the slot index where this instruction reads and writes OldLI. // This is usually the def slot, except for tied early clobbers. SlotIndex Idx = LIS.getInstructionIndex(*MI).getRegSlot(); if (VNInfo *VNI =

Hi Quentin, I have tried to find a test case for an official target, but failed. It seems to be a rare case. To do it, I added the 'else' clause in the following: ... if (VNI->def == OrigVNI->def) { DEBUG(dbgs() << "orig phi value\n"); SVI->second.DefByOrigPHI = true; SVI->second.AllDefsAreReloads = false; propagateSiblingValue(SVI); continue;

When compiling trunk using gcc 4.1.2 on linux/ppc64, I now see a warning that I don't remember seeing previously: llvm[2]: Compiling InlineSpiller.cpp for Release+Asserts build /src/llvm-trunk-dev/include/llvm/ADT/PointerIntPair.h: In member function ‘const PointerTy* llvm::PointerIntPair<PointerTy, IntBits, IntType, PtrTraits>::getAddrOfPointer() const [with PointerTy = void*, unsigned

Hi Quentin, I have rerun the test case on a recent commit, so the numbers have changed. There are also now a few more basic blocks very small basic blocks in the function, and therefore there are some slight differences. I tried to go back to earlier commits, without success for some reason... This is however very similar, except that there becomes two COPYs back to sibling value after the loop.

On Jan 17, 2008, at 1:49 PM, David Greene wrote: > Post-phi-elimination, when can a LiveInterval VNInfo have a ~1 or ~0 > def > value? I've seen ~0 on intervals created for spills. Can it happen > anywhere > else? They can be created during coalescing. Evan > > > -Dave >

Hi, It looks like LiveIntervals::addIntervalsForSpills does not update all of the LiveIntervals infos quite correctly. In particular, if a live interval L is defined by Reg<-Reg copy instructions whose srcReg is later spilled by the addIntervalsForSpills() function, its VNInfo information is not updated in a proper way. It still points to the same MachineInstr as before, even though the

On Aug 8, 2010, at 9:20 PM, Reid Kleckner wrote: > I thought I dug into the register allocation code, and found the > VNInfo::Allocator typedef. I assumed that was getting the traffic we > saw in Instruments, but I don't have the data to back that up. Are you using llvm from trunk? VNInfo is a lot smaller now than it was in 2.7. I would guess about a third of the liveness memory

On Sun, Aug 8, 2010 at 8:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 7, 2010, at 7:05 PM, Steven Noonan wrote: >> I've been doing work on memory reduction in Unladen Swallow, and >> during testing, LiveRanges seemed to be consuming one of the largest >> chunks of memory. > > That's interesting. How did you measure this? I'd

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> Are all of those sibling values guaranteed to ultimately derive from the >> same def, in the sense that they can be traced through copies, phis, >> etc. back to a single instruction? > > They are known the all come from the same value in the original live range from before live range splitting. Ok, that's

On Sun, Aug 8, 2010 at 9:20 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > On Sun, Aug 8, 2010 at 8:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> > wrote: > > > > On Aug 7, 2010, at 7:05 PM, Steven Noonan wrote: > >> I've been doing work on memory reduction in Unladen Swallow, and > >> during testing, LiveRanges seemed to be