similar to: [LLVMdev] Graph Coloring Regalloc

On 4/3/07, David Greene <greened at obbligato.org> wrote: > > I'm just starting to dive into llvm, hoping to implement a > good graph coloring register allocator. I gather that this > has been discussed before. > > What is the RegAllocGraphColoring.cpp currently in the > sources? It seems to be the Fred Chow algorithm but > it's not mentioned in the

Hi, --- Anton Vayvod <avayvod at gmail.com> wrote: > On 4/3/07, David Greene <greened at obbligato.org> wrote: > > > > I'm just starting to dive into llvm, hoping to implement a > > good graph coloring register allocator. I gather that this > > has been discussed before. > > > > What is the RegAllocGraphColoring.cpp currently in the >

Hey, Anton, yes, I have an implementation of a register allocator for LLVM. I Don't build the interference graph though. I perform a linear scan on the dominator tree. The difference from my algorithm to LLVM's linear scan is that I perform register allocation before the SSA-elimination step. I have it working, but did not commit, because I did not implement it using LLVM's

On 4/3/07, David Greene <greened at obbligato.org> wrote: > David Greene wrote: > > > What is the RegAllocGraphColoring.cpp currently in the > > sources? It seems to be the Fred Chow algorithm but > > it's not mentioned in the documentation anywhere. Does > > it work? > > Ah, ok. One of our folks here grabbed it off the mailing > list and put it

David Greene wrote: > What is the RegAllocGraphColoring.cpp currently in the > sources? It seems to be the Fred Chow algorithm but > it's not mentioned in the documentation anywhere. Does > it work? Ah, ok. One of our folks here grabbed it off the mailing list and put it in our local repository. Still, what's the status of this thing?

>> And I have a quite fast algo that I believe is simpler than [Budimlic02] >> and I can share it with you :) > > Do you have a paper on this? I'd be interested in seeing it. > Yes, I have a tech report on this page: http://compilers/fernando/projects/soc/ and I have submitted a paper to SAS, and now I am waiting for the review. The coalescing algorithm is described in

> And I have a quite fast algo that I believe is simpler than [Budimlic02] > and I can share it with you :) Do you have a paper on this? I'd be interested in seeing it. -Tanya > > Fernando > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >

Hi all, As I work toward improving LLVM register allocation, I've come across the need to do some refactoring. Specifically, I would like to separate register coalescing from live interval analysis. Right now LiveIntervals handles both. The reason I want to separate them is that other types of register allocators might like to do coalescing differently (e.g. graph coloring does it by

Dear LLVM guys, I am getting an error with my pass implementation, and I cannot figure it out. Basically, I've implemented part of a register allocation algorithm, but I am having problems to set the passes correctly. For instance, for this program below, the following error message is produced: .c ----------------------| .bc ---------------------------------

Hello, all, I want to implement the register allocation algorithm described in the paper "Register Allocation via Coloring of Chordal Graphs, APLAS'05" in LLVM. This is a graph coloring algorithm that can find an optimal coloring of the interference graph in most of the cases. I've downloaded LLVM last week, and started studying the code. Basically, I have to implement: 1) A

Dear LLVM guys, I've solved my problem with the passes, and compiled my first code using the new register allocator! Debugging was quite easy, using gdb. The problem was that I was forgetting to initialize the array that records the physical registers ever used (MachineFunction::UsedPhysRegs). This is a very minor thing, but I would suggest asserting that the vector has been initialized

Hi Florian, we though about using UIUC, like in LLVM. Do you guys know if that could be a problem, given that we are mining the functions from github? > Have you thought about integrating the benchmarks as external tests into LLVM’s test-suite? That would make it very easy to play around with. We did not think about it actually. But we would be happy to do it, if the community accepts

Hi Fernando, > Hi, Roman, > > we have an implementation of an allocator for LLVM that, like > Sarkar's, allows to split live ranges at any program point. You can > find > its description here: > > http://compilers.cs.ucla.edu/fernando/publications/drafts/long_PereiraPalsberg07.pdf > I've read your paper already. It is a very interesting approach! But

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 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 Fri, 23 Jun 2006, Fernando Magno Quintao Pereira wrote: > I am getting an error with my pass implementation, and I cannot figure > it out. Basically, I've implemented part of a register allocation > algorithm, but I am having problems to set the passes correctly. For > instance, for this program below, the following error message is > produced: It's hard to say

On Sat, 29 Apr 2006, Fernando Magno Quintao Pereira wrote: > I want to implement the register allocation algorithm described in the > paper "Register Allocation via Coloring of Chordal Graphs, APLAS'05" in > LLVM. This is a graph coloring algorithm that can find an optimal coloring > of the interference graph in most of the cases. I've downloaded LLVM last > week,

Fernando Magno Quintao Pereira wrote: > Yes, I have a tech report on this page: > > http://compilers/fernando/projects/soc/ Cool. I'm also interested in the Chordal Graph allocator. Are you planning to integrate it into the main llvm repository? It would make an interesting research project to compare allocation algorithms on real-world machines.

Dear LLVMers, we, at UFMG, have been building a large collection of compilable benchmarks. Today, we have one million C files, mined from open-source repositories, that compile into LLVM bytecodes (and from there to object files). To ensure compilation, we perform type inference on the C programs. Type inference lets us replace missing dependencies. The benchmarks are available at:

Dear Anton, you can add your register allocator strait iin the "lib/CodeGen/Passes.cpp", and then 're-make' it: "makellvm llc", on the top of lib/CodeGen. It is faster than running make from LLVMOBJDIR. The problem is that it only add to llc the changes on the lib/CodeGen directory. If you change other parts, a make from LLVMOBJDIR will synchronize it. Try adding