similar to: [LLVMdev] Regalloc Refactoring

Chris Lattner wrote: > On Thu, 12 Apr 2007, David Greene wrote: >> As I work toward improving LLVM register allocation, I've >> come across the need to do some refactoring. > > cool. :) One request: Evan is currently out on vacation until Monday. > This is an area that he is very interested in and will want to chime in > on. Please don't start anything

On Thu, 12 Apr 2007, David Greene wrote: > As I work toward improving LLVM register allocation, I've > come across the need to do some refactoring. cool. :) One request: Evan is currently out on vacation until Monday. This is an area that he is very interested in and will want to chime in on. Please don't start anything drastic until he gets back :). > Specifically, I would

On Thu, 12 Apr 2007, David Greene wrote: >> Beyond that, one of the issues is the "r2rmap" and "rep" function. As >> you've noticed, the coallescer basically uses these to avoid rewriting the >> code after it does coallescing. For example, if r1024 is coallesced with >> r1026, it leaves all uses of both registers in the code, instead of >>

On Apr 12, 2007, at 2:37 PM, David Greene wrote: > Chris Lattner wrote: >> On Thu, 12 Apr 2007, David Greene wrote: >>> As I work toward improving LLVM register allocation, I've >>> come across the need to do some refactoring. Yay! >> Beyond that, one of the issues is the "r2rmap" and "rep" >> function. As >> you've

Evan Cheng wrote: > the given infrastructure? Perhaps. But not without pain. The current > data structure is lacking detailed def-use info to properly determine > the correct split point. The register allocator even treat > "fixed" (i.e. physical register) intervals separately from other > active ones. > > The point is, the current code needs a lot of

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 >> passes down stream can recover from the earlier mistakes. By this, we >> mean live range splitting and re-materialization. > > Can you explain this a little

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 >>> passes down stream can recover from the earlier mistakes. By >>> this, we

Chris Lattner wrote: > On Thu, 12 Apr 2007, Fernando Magno Quintao Pereira wrote: >>> I'm definitely interested in improving coalescing and it sounds like >>> this would fall under that work. Do you have references to papers >>> that talk about the various algorithms? >> Some suggestions: >> >> @InProceedings{Budimlic02, >> AUTHOR =

On Apr 23, 2007, at 1:43 PM, Christopher Lamb wrote: > On Apr 23, 2007, at 1:17 PM, Christopher Lamb wrote: > >> On Apr 23, 2007, at 12:31 PM, Chris Lattner wrote: >> >>> On Mon, 23 Apr 2007, Christopher Lamb wrote: >>>> How can one let the back end know how to insert and extract >>>> elements of >>>> a vector through sub-register

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

On Thu, 12 Apr 2007, Fernando Magno Quintao Pereira wrote: >> I'm definitely interested in improving coalescing and it sounds like >> this would fall under that work. Do you have references to papers >> that talk about the various algorithms? > > Some suggestions: > > @InProceedings{Budimlic02, > AUTHOR = {Zoran Budimlic and Keith D. Cooper and Timothy

On Apr 18, 2007, at 9:10 AM, David Greene wrote: > Evan Cheng wrote: > >> the given infrastructure? Perhaps. But not without pain. The current >> data structure is lacking detailed def-use info to properly determine >> the correct split point. The register allocator even treat >> "fixed" (i.e. physical register) intervals separately from other >>

On Mon, 16 Apr 2007, David Greene wrote: >> Yep, this is the one I was thinking of. It is available online here: >> http://www.cs.rice.edu/~keith/LACSI/pldi02.pdf > > I was just looking at this today. One thing that strikes me about > all these papers I've read on the topic is that no one seems to > consider the interaction of coalescing with spilling. By definition

I don't understand the following code snippet in LiveIntervalAnalysis.cpp. Why changing the type of the opreand from a virtual register to a machine register? The register number (reg) is still a virtual register index (>1024). bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) { // perform a final pass over the instructions and compute spill // weights, coalesce

I'm targeting a language that uses virtual registers and not physical registers. So the easiest way to implement this is to use virtual registers, except that they are being restarted after each function and clobbering registers in previous functions. For example: start function 0 r1024 = mov %var0.0 r1025 = mov %var0.1 lots of intermediate code call function1 w/ 3 parameters more

No, there isn't something like that right now. What are you trying to accomplish? If you wish to implement this, it shouldn't be hard to do. Right now, MachineRegisterInfo re-starts virtual register number at TargetRegisterInfo::FirstVirtualRegister. You can add a mechanism to change that to a variable instead. Evan On Oct 20, 2008, at 1:43 PM, Villmow, Micah wrote: > Is

Is there currently a way to have virtual register allocation information be saved across functions so that if I create a new virtual register in a function that it doesn't use a virtual register allocated in any previous function? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054

Hello, I am new to LLVM and I am not sure whether I am writing to the right distribution list or not. Please let me know if this is not the right distribution list. Question: - I am having hard time lowering ADD instructions for different purposes. Basically, I want to have different machine instruction for pointer addition vs scalar addition. I am having hard time mapping LLVM add to my machine

On Monday 16 July 2007 18:20, Evan Cheng wrote: > > Does the current implementation follow a published algorithm? If > > so, do we > > have a pointer to it? The comments are rather sparse and it's > > difficult to > > figure out what's going on at times. > > I don't know. I suspect not. I agree the current implementation is a > bit of a

Chris Lattner wrote: >> Doesn't that last statement actually do the rewrite? > > Hrm, yes, yes it appears so. Question is: doesn't this make the r2r map > dead? Does something else fill it in? My memory is hazy here :). If it > is dead, we should rip it out (actually, we should make it private to the > coallescer function). I'm trying an experiment to