search for: vninfo

...d 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 = OldLI.getVNInfoAt(Idx.getRegSlot(true))) if (SlotIndex::isSameInstr(Idx, VNI->def)) Idx = VNI->def; Comments in SlotIndexes.h have this to say: /// Early-clobber register use/def slot. A live range defined at /// Slot_EarlyCLobber interferes with normal liv...

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 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), beca...

...c/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 int IntBits = 1u, IntType = bool, PtrTraits = llvm::PointerUnionUIntTraits<llvm::VNInfo*, llvm::SmallVector<llvm::VNInfo*, 4u>*>]’: /src/llvm-trunk-dev/include/llvm/ADT/PointerUnion.h:153: instantiated from ‘const PT1* llvm::PointerUnion<PT1, PT2>::getAddrOf() const [with T = llvm::VNInfo*, PT1 = llvm::VNInfo*, PT2 = llvm::SmallVector<llvm::VNInfo*, 4u>*]’ /src/...

...huge function. If it's a coalescing bug it's probably in my code since I'm not using the current default llvm coalescer. It may be that I'm updating dataflow information incorrectly. I'll check on that. > > If so, then isn't LiveInterval::Ranges and LiveInterval::VNInfoList > > redundant? > > What's in VNInfoList that's not in the valno member of the Ranges > > elements, > > and vice-versa? > > I am not sure if I understand your question. Multiple liveranges can > be of the same val#. Each VNInfo contains definition (if not...

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

...cing 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, const VNInfo *RHSValNo, VNInfo *LHSValNo) { SmallVector<VNInfo*, 4> ReplacedValNos; iterator IP = begin(); for (const_iterator I = RHS.begin(), E = RHS.end(); I != E; ++I) { if (I->valno != RHSValNo) continue; unsigned Start = I->start, End = I->end; IP = std::upper_bound...

...rue; >> SVI->second.AllDefsAreReloads = false; >> propagateSiblingValue(SVI); >> continue; >> } >> // check if the valno is actually an orig PHI, but is not OrigVNI >> else { >> LiveInterval &OrigLI = LIS.getInterval(Original); >> VNInfo *OrigVNI_curr = OrigLI.getVNInfoAt(VNI->def); >> if (OrigVNI_curr->def == VNI->def) >> assert(0 && "OrigLI contained VNI which was a PHI, but not OrigVNI!"); >> } >> >> , but the assert never triggered anywhere else than in my origina...

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

...consuming one of the largest >> chunks of memory. > > That's interesting. How did you measure this? I'd love to see your data. > > Note that the LiveRange struct is allocated by a plain std::vector, and your patch doesn't change that. I assume you are talking about the VNInfo structs? Steven has been using Instruments, and sending us screenshots. Does anyone else know a better way of exporting that data? 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&...

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 usage goes through the VNInfo Bum...

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

...k. It could be a bug. Can you get me a test case? > > > A related question: LiveRange::valno is a single value, correct? In > other > words it doesn't point to an array or anything, right? Correct. > > > If so, then isn't LiveInterval::Ranges and LiveInterval::VNInfoList > redundant? > What's in VNInfoList that's not in the valno member of the Ranges > elements, > and vice-versa? I am not sure if I understand your question. Multiple liveranges can be of the same val#. Each VNInfo contains definition (if not containing a phi merge, e...

...%reg1055 doesn't appear anywhere else in the program so it shouldn't be live-in to the block. A related question: LiveRange::valno is a single value, correct? In other words it doesn't point to an array or anything, right? If so, then isn't LiveInterval::Ranges and LiveInterval::VNInfoList redundant? What's in VNInfoList that's not in the valno member of the Ranges elements, and vice-versa? -Dave

...come from the same value in the original live range from before live range splitting. Ok, that's exactly what I need. > The defining instruction may not exists any longer. It could have been > rematerialized somewhere else. It could also have been PHI. Ok, so in that case the traced-to VNInfo will have a def SlotIndex of Slot_Block or something? -David

...ly clobber applies to a defined register and it prevents the register allocator from using it as an input register. > My problem boils down to trying to find the defining instruction for a > virtual register use. Given an instruction using register A, I want to > be able to look at the VNInfo at the instruction's register use slot and > see what VNInfo::def points to. Some scenarios I want to understand: > > 4B A = ... > 10B D = use A > > This seems straightforward. The instruction at slot 10 uses A at 10r > and the VNInfo for 10r should have a def at 4r. &gt...

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

...; 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, > const VNInfo *RHSValNo, VNInfo > *LHSValNo) > { > SmallVector<VNInfo*, 4> ReplacedValNos; > iterator IP = begin(); > for (const_iterator I = RHS.begin(), E = RHS.end(); I != E; ++I) { > if (I->valno != RHSValNo) > continue; > unsigned Start = I->start, End = I...