similar to: [LLVMdev] Register allocator assert

On Fri, 2004-08-27 at 08:05, Vladimir Prus wrote: > Hello, > I'm getting an assertion in register allocator, specifically in > LiveIntervalAnalysis.h, method LiveIntervals::getInstructionIndex: > > unsigned getInstructionIndex(MachineInstr* instr) const { > Mi2IndexMap::const_iterator it = mi2iMap_.find(instr); > assert(it != mi2iMap_.end() &&

Thanks. One question though. Should getMBBFromIndex() assert if given an index out of the range or simply returns a NULL pointer? I would think the later makes it a bit more friendly. Evan On Feb 8, 2008, at 8:59 AM, Roman Levenstein wrote: > Hi Evan, > > Here is a patch for the LiveIntervalAnalysis that we discussed. > > --- Evan Cheng <evan.cheng at apple.com>

Hi Evan, --- Evan Cheng <evan.cheng at apple.com> wrote: > Thanks. One question though. Should getMBBFromIndex() assert if given > an index out of the range or simply returns a NULL pointer? I would > think the later makes it a bit more friendly. Yes. It would be more friendly, probably. I can submit such a patch, if you think it suits better. On the other hand I want to

Hi Evan, Here is a patch for the LiveIntervalAnalysis that we discussed. --- Evan Cheng <evan.cheng at apple.com> schrieb: > > 1) What is the easiest way to understand which MBB a given > instruction index belongs to? All the required information is > available in the > > MBB2IdxMap of the LiveIntervalAnalysis class. Would it be useful > to add a small function

On Feb 10, 2008, at 11:44 PM, Roman Levenstein wrote: > Hi Evan, > > --- Evan Cheng <evan.cheng at apple.com> wrote: > >> Thanks. One question though. Should getMBBFromIndex() assert if given >> an index out of the range or simply returns a NULL pointer? I would >> think the later makes it a bit more friendly. > > Yes. It would be more friendly, probably.

I would like to make a suggestion. In the LiveIntervalAnalysis class, instead of numbering the instructions in the order in which basic blocks are stored in the machine function, use the df_ext_iterator. It will order the instruction according to the dominance tree (or it seems to be doing so). There are many advantages in doing this. One of them is that, once you traverse the dominance tree

On Thu, 21 Jun 2007, Fernando Magno Quintao Pereira wrote: > I would like to make a suggestion. In the LiveIntervalAnalysis class, > instead of numbering the instructions in the order in which basic blocks > are stored in the machine function, use the df_ext_iterator. It will order > the instruction according to the dominance tree (or it seems to be doing > so). There are many

Nice idea. Please also try using SmallPtrSet (with a sufficiently large size) instead of std::set for traversal after everything is working. Using std::set can really hurt compile time in case of large basic block numbers. Is there a way to dynamically adjust "SmallSize" based on number of basic blocks in the function? Evan On Jun 21, 2007, at 10:20 PM, Fernando Magno Quintao

Hi, In the LiveIntervalAnalysis::runOnMachineFunction, there is a code to compute the MBB2IdxMap, by remembering for each MBB its start and end instruction numbers: unsigned MIIndex = 0; for (MachineFunction::iterator MBB = mf_->begin(), E = mf_->end(); MBB != E; ++MBB) { unsigned StartIdx = MIIndex; for (MachineBasicBlock::iterator I = MBB->begin(), E =

I am looking for the slot index of a register around the given slot index Min. Is there a better way than the linear search: ... findDefUsesAroundIndex( LiveInterval* li, SlotIndex Min ) ... for( MachineOperand * mo = MRI->getRegUseDefListHead(li->reg); mo; mo = mo->getNextOperandForReg() ) { SlotIndex si = SI->getInstructionIndex( use.getOperand().getParent() ); if(

Hi I'm seeing something probably related to this. I'm getting an assert from the lower_bound in LiveIntervals::findLiveinMBBs (from a checking std:: VS2005 implementation). Idx2MBBMap has two elements in it, both of which have a .first of 0. (I believe because of an empty MBB in the function below, so StartIndex doesn't advance). scott On Wed, Apr 16, 2008 at 2:52 AM, Roman

Can you file a bug so I don't forget? I'm a little occupied right now. But I'll take care of this soon. Evan On Apr 16, 2008, at 10:52 AM, Scott Graham wrote: > Hi > > I'm seeing something probably related to this. I'm getting an assert > from the lower_bound in LiveIntervals::findLiveinMBBs (from a checking > std:: VS2005 implementation). Idx2MBBMap has two

Lang, I think I am getting closer to understanding this. The findLastUseBefore() should probably look something like this: // Return the last use of reg between NewIdx and OldIdx. SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) { SlotIndex LastUse = NewIdx; if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitRootIterator Roots(Reg,

Hello LLVM Developers, We are working on extending currently available register rematerialization to include cases where sequence of multiple instructions is required to rematerialize a value. We had a discussion on this in community mailing list and link is here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/subject.html#104777 >From the above discussion and studying the code we

On Oct 5, 2007, at 5:52 PM, David Greene wrote: > > In LiveIntervalAnalysis::addIntervalsForSpills, we have this: > > if (HasUse) { > LiveRange LR(getLoadIndex(index), getUseIndex(index), > nI.getNextValue(~0U, 0, VNInfoAllocator)); > DOUT << " +" << LR; > nI.addRange(LR); >

I'm debugging my iterated coalescing implementation and I've come across what I think is an inconsistency in spill code interval generation. The bug shows up when there's a copy that has its source register spilled. When the coalescer comes back around to try to coalesce the copy, the merge code complains that there are no values copied from the RHS. For example: Examining copy

I have a live interval, and I would like to find out what SlotIndex the next use the register will occur? Is there any way to map a live interval back into instructions or SlotIndexes or blocks used by? - Thanks Jeff Kunkel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110120/fd429dbd/attachment.html>

Hi, Just my two cents: If I recall correctly, in some papers on the linear scan register allocation people described that they tried different orderings for instruction numbering, e.g. including DFS or based on the loop nesting levels, etc. There was no clear winner though. But let's see the numbers anyway. May be it really brings some improvements. -Roman Chris Lattner wrote: > On

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 Lang, Just one more quick question. in LiveIntervalAnalysis.cpp In SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) Did you really mean to use for (MachineRegisterInfo::use_nodbg_iterator UI = MRI.use_nodbg_begin(Reg), UE = MRI.use_nodbg_end(); UI != UE; UI.skipInstruction()) {} Aren't we currently dealing with units,