search for: vninfos

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 =

.... It still points to the same MachineInstr as before, even though the MachineInstr was rewritten by addIntervalsForSpills(). This may lead to some problems during coalescing attempts after spilling (I'm trying to do coalescing in an iterative way), because the assertion in the LiveIntervals::getVNInfoSourceReg() fails due to the fact that the copy instruction defining the VNInfo of the live interval L is not a Reg<-Reg move any more. It is a Reg<-Mem move after spilling function invocation. How should such a situation with VNInfos be handled in a proper way? Any suggestions? Thanks, -Ro...

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

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

In LLVM 3.1, given a VNInfo, how do I get the range information for that value? I've tried looking at the MachineInstr at the def point, getting its defined register and looking at LiveIntervals to get an interval for the register, but that doesn't always return something sane. I'm in the middle of InlineSpiller so LiveRangeEdit is in play. Thanks for your help!

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 50. MergeValueInAsValue has this code: void LiveInterval::MergeValueInAsValue(const LiveInterval &RHS,

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've hit a bug in a refactored version of coalescing and I'm trying to understand what is going on. In particular, I'm curious about this line in SimpleRegisterCoalescing.cpp: 00710 LHSValsDefinedFromRHS[VNI] = RHS.getLiveRangeContaining(VNI->def-1)->valno; Why VNI->def-1? The bug I'm seeing is that RHS returns a NULL LiveRange because it doesn't contain

On Tuesday 25 September 2007 10:49, David Greene wrote: > I've hit a bug in a refactored version of coalescing and I'm trying to > understand what is going on. In particular, I'm curious about this > line in SimpleRegisterCoalescing.cpp: > > 00710 LHSValsDefinedFromRHS[VNI] = > RHS.getLiveRangeContaining(VNI->def-1)->valno; > > Why VNI->def-1?

On Tuesday 25 September 2007 12:25, Evan Cheng wrote: > LLVM is assuming this: > struct InstrSlots { > enum { > LOAD = 0, > USE = 1, > DEF = 2, > STORE = 3, > NUM = 4 > }; > > So VNI->def is always modulo 2. For coalescing, it's checking if the > RHS is live at the "use"

On Tuesday 25 September 2007 13:28, David Greene wrote: > > So VNI->def is always modulo 2. For coalescing, it's checking if the > > RHS is live at the "use" cycle. So it's checking VNI->def-1. > > But why is it looking at a use slot in this case, where the coalescer is > trying to get the vaue number for the def of the RHS register so it can > use

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

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

LLVM is assuming this: struct InstrSlots { enum { LOAD = 0, USE = 1, DEF = 2, STORE = 3, NUM = 4 }; So VNI->def is always modulo 2. For coalescing, it's checking if the RHS is live at the "use" cycle. So it's checking VNI->def-1. Evan On Sep 25, 2007, at 8:55 AM, David Greene wrote: > On Tuesday

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>

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

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 12/22/2016 4:02 PM, via llvm-dev wrote: > > /// Early-clobber register use/def slot. A live range defined at > /// Slot_EarlyCLobber interferes with normal live ranges killed at > /// Slot_Register. Also used as the kill slot for live ranges tied to an > /// early-clobber def. > Slot_EarlyClobber, > > What does this mean, exactly? My

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

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