search for: regallocbase

Hi everyone, I'm quite new to LLVM *and doing a Q-learning *(*just a hobby*)* on register allocation for LLVM. RegAllocRL is based on* *RegAllocBase*,* RegAllocBasic and add some feature to implement Q-learning algorithm. * *I*’*ve currently run as MachineFunctionPass and things seem to work in simple case. In order to make progress on training*, *I have questions and want to get some help:* 1. *Is there any file data format used in LLVM...

I'm working on my project for completion undergraduate courses, consisting of an experimental analysis of registers allocation algorithms. For this task, I am using the set of tools from the LLVM project. However, I have read the documentation of the LLVM project and not yet found a way to put the pieces of the puzzle together. So far I know: - As passes work as engage them to LLVM and

My god! I would love a branch predictor! It would simplify many aspects of my register allocator. Second, I am surprised it did not make it into the tree. Since more is being done with register allocation as a while "RegAllocBasic" was just put in, I hope this is looked at again. Do you have a working svn copy? Also, could you send me a copy/link to that '94 paper off the list

...is not even a serious alternative to RegAllocGreedy at the moment, due to the poor handling of spilling. As Arnaud wrote below, it is not optimizing spilling at all, but rather just spills anything that does not get an assignment. The result is a lot more spill/reload instructions than needed. In RegAllocBase.h it says "...Register allocation complexity, and generated code performance is determined by the effectiveness of live range splitting rather than optimal coloring...". I would then think that any register allocation algorithm should benefit from this, but find that only RegAllocGreedy i...

You said it was expensive, but if you had to put a big-o estimate on it, what would it be? -Thanks Jeff Kunkel On Tue, Nov 2, 2010 at 8:54 PM, Andrei Alvares <logytech at gmail.com> wrote: > Hello Jeff, > > On Tue, Nov 2, 2010 at 9:17 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > > My god! I would love a branch predictor! It would simplify many aspects > of >

Hello Jeff, On Tue, Nov 2, 2010 at 9:17 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > My god! I would love a branch predictor! It would simplify many aspects of > my register allocator. The branch predictor of the implementation is not as accurate as the one from the paper, but it is close enough. Unfortunately, the branch predictor is a very expensive pass, because it relies on

Hi Jeff, There is an algorithm to build the dominator tree that is O(n2), where n is the number of nodes on the control flow graph. I believe exists another that is linear, but I don't which one of them is implemented in LLVM. The problem is that the branch predictor requires post dominance information. None of the LLVM basic passes require post dominance information (AFAIK), hence it is

...ative to > RegAllocGreedy at the moment, due to the poor handling of spilling. As > Arnaud wrote below, it is not optimizing spilling at all, but rather just > spills anything that does not get an assignment. The result is a lot more > spill/reload instructions than needed. > > In RegAllocBase.h it says “…Register allocation complexity, and generated > code performance is determined by the effectiveness of live range splitting > rather than optimal coloring…”. I would then think that any register > allocation algorithm should benefit from this, but find that only > RegAllocGr...

Just a quick question: is greedy still a local allocator (i.e. only takes into consideration the current bb) or a global one (takes into consideration the whole function)? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110926/d87aa2bd/attachment.html> -------------- next part -------------- A non-text

...not even a serious alternative to RegAllocGreedy at the moment, due to the poor handling of spilling. As Arnaud wrote below, it is not optimizing spilling at all, but rather just spills anything that does not get an assignment. The result is a lot more spill/reload instructions than needed. In RegAllocBase.h it says “…Register allocation complexity, and generated code performance is determined by the effectiveness of live range splitting rather than optimal coloring…”. I would then think that any register allocation algorithm should benefit from this, but find that only RegAllocGreedy is doing live r...

Hi, I'm working on live intervals and I'm curious about how LLVM typically would represent live info. Take the following case (after SimpleRegisterCoalescer): BB#3: derived from LLVM BB %bb.nph Live Ins: %a0_h Predecessors according to CFG: BB#2 %reg16500<def> = COPY %reg16499 Successors according to CFG: BB#4 BB#4: derived from LLVM BB %for.body21 Live Ins:

Hello, I'm trying to evaluate the different register allocation algorithms on LLVM using the same level of optimizations. Using version 3.3 the current register allocators available to use are "basic, fast, greedy and pbqp". However, I'm facing the following issues: 1) I can't run basic and PBQP allocators using the command line flags of the dragonegg

Hi, I would like to ask about PBQPs use of InlineSpiller. The code output when using PBQP gets a lot bigger compared to when using RegAllocGreedy. PBQP does not split the live intervals, and a lot more (often redundant) reload instructions are emitted as a result, it seems. I wonder why this is, and if there are any plans to improve on this point? /Jonas Paulsson -------------- next part

Thanks Andrei! I haven't read the paper. I would see whether this fulfills my requirements or whether I need to make any changes. --Kapil On Tue, Nov 2, 2010 at 12:43 PM, Andrei Alvares <logytech at gmail.com> wrote: > Hello Kapil, > > I have implemented a static profiler for LLVM as a google summer of > code project in 2009. I wrote it for the 2.4 branch, but the >

I just uploaded a blog post outlining the new register allocation algorithm in LLVM 3.0. http://blog.llvm.org/2011/09/greedy-register-allocation-in-llvm-30.html Please direct comments here. /jakob

On Sep 26, 2011, at 4:22 AM, Leo Romanoff wrote: > Hi Jakob, > > Thanks for a very interesting description of the new register allocation algorithm in LLVM!!! > > Could you elaborate a bit on the following topics: > > 1) Do you have any plans to publish something more formal and detailed about this algorithm, e.g. a paper or something similar? It would be nice to better

Hello Kapil, I have implemented a static profiler for LLVM as a google summer of code project in 2009. I wrote it for the 2.4 branch, but the implementation never made into the tree. I have recently ported it to LLVM 2.8, but I haven't tested it. You can take a look at the code from: http://homepages.dcc.ufmg.br/~rimsa/tools/stprof-llvm.patch The implementation is based on Wu's

...1af75 llvm::LiveRangeEdit::eliminateDeadDefs(llvm::SmallVectorImpl<llvm::MachineInstr*>&, llvm::ArrayRef<unsigned int>) + 949 5 libLLVM-3.1.so 0x00002b989ebf2142 6 libLLVM-3.1.so 0x00002b989ebf297c 7 libLLVM-3.1.so 0x00002b989ecacb67 8 libLLVM-3.1.so 0x00002b989ec9ed65 llvm::RegAllocBase::allocatePhysRegs() + 181 9 libLLVM-3.1.so 0x00002b989ecad4ce 10 libLLVM-3.1.so 0x00002b989ec4eb10 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 96 11 libLLVM-3.1.so 0x00002b989ede6731 llvm::FPPassManager::runOnFunction(llvm::Function&) + 561 12 libLLVM-3.1.so 0x00002b989...

Hi all, I've come across a problem with register allocation which I have been unable to track down the root cause of. 6728B %vreg304<def> = COPY %vreg278; VRF128:%vreg304,%vreg278 6736B %vreg302<def> = COPY %vreg278; VRF128:%vreg302,%vreg278 6752B %vreg278<def,tied1> = foo %vreg278<tied0>, %vreg277, 14, pred:1, pred:%noreg, 5; VRF128:%vreg278 VRF64_l:%vreg277 * bar

Hi Jakob, Hi Andy, First of all, thanks a lot for very elaborative and interesting answers! > It may be more helpful to explain how LLVM's register allocator came > into existence before debating the high level algorithm. > > When I began working on LLVM last October, Jakob was developing an > infrastructure for global live range splitting. It was just becoming > clear