search for: regallocbasic

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 to store informa...

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 please? -Thanks -Jeff Kunkel On Tue, Nov 2, 2010 at 6:57 PM, kapil anand <kapilanand2 at gmail.com> wrote: > Thanks Andrei! &gt...

Hi, I have worked a little on the PBQP register allocator, and it is quite clear (at least to me) that it 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

...predictor is a very expensive pass, because it relies on post > domination information for some heuristics which is costly to > calculate. > > > 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? > > I created the patch based on the official 2.8 branch release, but as I > said before I didn't get the time to fully tested it on this release. > > > Also, could...

...gh. Unfortunately, the branch predictor is a very expensive pass, because it relies on post domination information for some heuristics which is costly to calculate. > 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? I created the patch based on the official 2.8 branch release, but as I said before I didn't get the time to fully tested it on this release. > Also, could you send me a copy/link to that '9...

...e pass, because it relies on post >> domination information for some heuristics which is costly to >> calculate. >> >> > 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? >> >> I created the patch based on the official 2.8 branch release, but as I >> said before I didn't get the time to fully tested it on this release...

Hi Quentin, Jonas, Splitting fits in with PBQP reasonably well, at least conceptually. The PBQP graph is designed to be mutable, so there is no problem with updating it when splitting. As I see it, there are two logical places to integrate splitting into PBQP: 1) Split during spilling -- If a PBQP solution selects the spill option for a node, rather than spill immediately, split the interval

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

Both approaches are not exclusive. I would even think it makes sense to have a pre-split pass to prepare the graph, with a global view, and later on use use trySplit (or an equivalent) to handle the local coloring issues. From: Quentin Colombet [mailto:qcolombet at apple.com] Sent: 09 March 2015 23:08 To: Lang Hames Cc: Jonas Paulsson; llvmdev at cs.uiuc.edu; Arnaud De Grandmaison Subject:

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

...s, and incrementally update every bit of state in the allocator. There is no abandoning the current solution and no iterative application of an algorithm. When I implemented the Basic/Greedy prototypes, I was able to replace the code in RegAllocLinearScan.cpp with the code you can still see in RegAllocBasic.cpp. You can see for yourself what Jakob means by the new allocator being much simpler. And as Jakob explained, the real benefit will be in removing VirtRegWriter.cpp which is made possible by his spill code optimizations. Those optimizations are in turn made practical by the new framework for incr...

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

Hi, I want to use LLVM 3.1 (with clang for the frontend) for compiling Open-MPI 1.6.3, which is a message-passing library. But I get a segmentation fault by the "Greedy Register Allocator". There is the bug # 11756 that solves a similar problem, but the bugzilla says "Version 3.0", and I am using 3.1 so it is likely a different bug that I am dealing with.

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

...handle overlapping register classes. A few names to be mentioned in these areas  are for example Hack, Bouchez, Boissinot, Pereira, Wimmer, etc > When I implemented the Basic/Greedy prototypes, I was able to replace > the code in RegAllocLinearScan.cpp with the code you can still see in > RegAllocBasic.cpp. You can see for yourself what Jakob means by the > new allocator being much simpler. And as Jakob explained, the real > benefit will be in removing VirtRegWriter.cpp which is made possibler c > by his spill code optimizations. Those optimizations are in turn made > practical by the...