similar to: [LLVMdev] Possible bug in LiveIntervalAnalysis?

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

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

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

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.

Hi, guys, sometimes it would be good if I could get the maximum instruction index from the set of live intervals. In my local version I have added this method to LiveIntervals: /// Return the maximum index among the instruction indices. inline unsigned getMaxInstrIndex() const { return i2miMap_.size() * InstrSlots::NUM; } Is there something like this already in LiveIntervals? Do you

Hi, I'm trying to sketch an LLVM-based implementation of the Extended Linear Scan algorithm, described in this Vivek Sarkar's paper: http://www.cs.rice.edu/~vs3/PDF/cc2007.pdf Sarkar reports that this version of Linear Scan produces better code than graph-coloring regallocs and is also much faster (15x to 68x). I already started work on the implementation of this algorithm and have a few

Hi Roman, > I already started work on the implementation of this algorithm and have > a few hopefully rather simple questions: > > 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

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() && "Invalid instruction!"); return it->second; } The crash happens

On Jan 31, 2008, at 5:05 AM, Roman Levenstein wrote: > Hi, > > I'm trying to sketch an LLVM-based implementation of the Extended > Linear Scan algorithm, described in this Vivek Sarkar's paper: > http://www.cs.rice.edu/~vs3/PDF/cc2007.pdf > Sarkar reports that this version of Linear Scan produces better code > than graph-coloring regallocs and is also much faster (15x

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() &&

I ran into some odd code being generated today and I came across something that doesn't look quite right. In SelectionDAGBuilder::visitShuffleVector there's some code to see if we can convert the shuffle to an EXTRACT_SUBVECTOR. After computing min/max values of the mask for each operand, there's a look that looks at the ranges and determines whether an EXTRACT_SUBVECTOR can be used:

Hi, I am writing an llvm pass wherein I require to iterate MachineBasicBlocks in reverse. The ilist reverse_iterator is not functioning as expected. Nor is the ilist iterator working in reverse (although -- operator is overloaded to do so). for (MachineFunction::iterator MBBI = mf_->end(), E = mf_->begin();MBBI != E; --MBBI) { MachineBasicBlock *MBB = MBBI;

On darwin x86, I'm seeing: $ make ENABLE_OPTIMIZED=1 llvm[2]: Compiling LiveIntervalAnalysis.cpp for Release build Assertion failed: (MVT::isInteger(LVT)), function MeetsMaxMemopRequirement, file /Volumes/mrs5/net/llvm/llvm/lib/CodeGen/ SelectionDAG/SelectionDAGISel.cpp, line 4230. /Volumes/mrs5/net/llvm/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1466: internal compiler error: Abort trap

I'm debugging a problem with a custom pass and I was surprised to discover that LiveIntervalAnalysis depends on PHIElimination. Why is that so? Intervals could be useful for all sorts of things beyond register allocation. Just curious. Is there something about the design of LiveIntervals that it needs the out-of-SSA conversion? -Dave