similar to: [LLVMdev] New Register Allocation Algorithm

Hi Fernando, On Jul 18, 2007, at 10:57 AM, Fernando Magno Quintao Pereira wrote: > > Dear LLVMers, > > we here in the UCLA compiler's lab have an implementation of a > very > cool register allocator in LLVM. It finds an optimal register > assignment > for the x86 machine, via live range splitting, that is, if it is > possible > to have a register

Hi Evan, I have a few questions about current implementation of live intervals spilling, which is required for the implementation of Extended Linear Scan algorithm. --- Evan Cheng <evan.cheng at apple.com> wrote: > > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: > >>> Evan, > >>> >

Hi, Roman, maybe I can try to answer this. I think that all boils down to having register to reload spilled values. Once a register is spilled, its live range is split into smaller pieces. These pieces most be contained into registers, and it is the task of the allocator to find these registers. Imagine that you have something like: Before After allocation: allocation: a

I'm not sure about one thing: you assign stack slot to each new register you replace the spilled one with. And then you need to allocate physical registers to them. Is it possible to assign physical register to the virtual one which has a stack slot already? On 8/21/06, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > > So what addIntervalsToSpills

Hi, right now, LLVM does register spilling by: 1. Creating stack object 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot 3. At later stage, frame indices are replaced by calling to MRegisterInfo::eliminateFrameIndex. This works for me, but there's slight problem. The target does not have "register + contant" addressing mode, so accessing frame index

On Tue, 23 May 2006, Vladimir Prus wrote: > right now, LLVM does register spilling by: > > 1. Creating stack object > 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot > 3. At later stage, frame indices are replaced by calling to > MRegisterInfo::eliminateFrameIndex. > > This works for me, but there's slight problem. The target does not have

Hi Fernando, --- Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > Hi, Roman, > > maybe I can try to answer this. I think that all boils down to > having register to reload spilled values. Ok. That I can follow. > Once a register is spilled, its live range is split into smaller > pieces. These pieces most be contained into registers, and

--- Evan Cheng <evan.cheng at apple.com> wrote: > > On Apr 17, 2007, at 2:24 PM, Chris Lattner wrote: > > > On Tue, 17 Apr 2007, David Greene wrote: > >> Evan Cheng wrote: > >>> Obviously, smart heuristics can make a big difference here > >>> (estimated > >>> register pressures, etc.) But the more important thing is how the

I will be removing RegAllocLinearScan and VirtRegRewriter from trunk shortly after we cut the 3.0 release branch. LLVM 3.0 will still ship with the linear scan register allocator, but the default will be the new greedy allocator. Linear scan can be enabled by passing '-regalloc=linearscan -join-physregs' to llc. RegAllocLinearScan and VirtRegRewriter need to go away soon because they

Dear LLVMers, I am trying to fold memory operands in the way that is done in RegAllocLocal.cpp, or in LiveIntervalAnalysis.cpp, but I am getting errors that I don't know how to fix. Could someone tell me which steps should I take in order to correctly fold memory operands? The code that I am using is: const TargetMachine & target_machine = this->machine_function->getTarget();

Fernando Magno Quintao Pereira wrote: >> I'm not sure about one thing: you assign stack slot to each new register you >> replace the spilled one with. And then you need to allocate physical >> registers to them. Is it possible to assign physical register to the virtual >> one which has a stack slot already? >> > > Yes. The stack slot is the place where the

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

Dear LLVMers OK, when I signed up for this mailing list, I asked for a once-daily digest. This is the fourth digest I receive today, and there are about that many each day. The only reason I subscribe to the mailing list is so I can post to it. But I don't need to receive the emails, because I can fully well read them in the archive online, and I certainly don't want to get spammed

On Aug 13, 2006, at 11:16 PM, Fernando Magno Quintao Pereira wrote: > > Dear LLVMers, > > I am trying to fold memory operands in the way that is done in > RegAllocLocal.cpp, or in LiveIntervalAnalysis.cpp, but I am getting > errors > that > I don't know how to fix. Could someone tell me which steps should I > take > in order > to correctly fold memory

On 11/23/07, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > Hi, Sanjiv, > > those passes operate on the whole machine function. Each machine > function contains many basic blocks. If a program has many functions, the > register allocator will be called as many times, i.e it does not do > interprocedural allocation. > > best, > >

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'm not sure about one thing: you assign stack slot to each new register you > replace the spilled one with. And then you need to allocate physical > registers to them. Is it possible to assign physical register to the virtual > one which has a stack slot already? > Yes. The stack slot is the place where the value will be stored in memory, but, when that value is effectively

Hi, again, I think you can do it in the same way that the other allocators have been coded, i.e extend RA, register the pass and so forth. I am not sure about the best way to pass information among a run of RegAlloc to the other, maybe the other guys in the list could suggest something. Yet, you can always dump it into a file, and read it again, everytime it is necessary. Remember that

Thanks again. One more question here: Since the regalloc works once per function, do I stil have access to the Call graph? Just saving information between regalloc passes for different functions may not be enough for my case. I will need to maintain the regalloc info of various passes in the call graph order. Anyways thanks for your inputs. I will get back if I need to learn more. Sanjiv On Nov

> Hi Fernando, > > It's hard to say exactly what's happening because I don't know your > code (though, from the stack trace, it seems like there's some sort > of memory debacle), but looking at the comment in the > LiveVariableAnalysis.cpp file where it's folding memory operands, it > might explain somethings better: > > // Folding the