similar to: [LLVMdev] Evaluating the register allocators

Hello LLVM developers, I'm assisting my doctor who is doing a research and he wants to use the llvm compiler, my job is to profile build the benchmarks using llvm-prof. What i want to know is the following 1- does llvm support profile feedback optimizations!? 2- when i've used the llvm-prof it's input is an object file (not binary as other compilers) my question is how could I

Hi Najem, On Mar 21, 2011, at 9:47 AM, NaJeM ErMeLeH wrote: > I'm assisting my doctor who is doing a research and he wants to use the llvm compiler, my job is to profile build the benchmarks using llvm-prof. > > What i want to know is the following > > 1- does llvm support profile feedback optimizations!? Not yet. Please see Bob's proposal:

Dear Najem, You might want to read the llvm-prof documentation if you haven't already: http://llvm.org/cmds/llvm-prof.html. The documentation mentions a script in the utils directory that automates some of the profiling tasks for you. I suspect the way that llvm-prof works is to compile your whole program to a single LLVM bitcode file, run a transform on it, and then generate native

Hello, I'm trying to evaluate the performance improvement of instruction scheduling on one of the inorder ARM processor, I was looking for ARM simulator and I found two (Simplescalar/ARM and SimIt-ARM) The code generated using llvm-2.9 and llvm-gcc and gcc 3.2. I used these command : $ llvm-gcc -O3 -o test1.bc -c --emit-llvm test1.c $ llc -O3 -o test1.s -march=arm test1.bc -mcpu=strongarm110

Hi Arnaud, Thanks for attaching those files. I'll take a look at them. Commit r153483 adds an option to the PBQP allocator, "-pbqp-dump-graphs", to dump the PBQP graph for each round of each function in a compilation unit. The generated files are named "<module id>.<function>.<round>.pbqpgraph", and contain a simple text representation of the PBQP graph.

Hi, Sorry for the delay, it has taken some extra time as more than one bug showed up ☺ I continued to look into this with your viewpoint that a node that is conservatively allocatable should never be spilled. The first thing I did was therefore to add some extra code with an assert for this. I believe I then found three bugs and fixed the two: Bug 1: Incorrect transpositions in handleAddEdge()

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

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 Lang, I have reduced the testcase as much as possible. The log of the run and the dumped graphes are attached. Cheers, -- Arnaud de Grandmaison On Tuesday, March 27, 2012 01:20:35 Lang Hames wrote: > Hi Arnaud, > > Thanks for attaching those files. I'll take a look at them. > > Commit r153483 adds an option to the PBQP allocator, > "-pbqp-dump-graphs", to

Hi All, I've just committed some changes to the PBQP allocator which are designed to make it easier to implement custom register allocation constraints. This is a quick summary of those changes, and of the status of the PBQP allocator in general. First a quick bit of background: The PBQP allocator is based on ideas described in [1]. I implemented this algorithm (with the improved heuristic

Hi Lang, The assert is not triggered any longer on my testcases :) I however still get my wrong allocation in some non trivial cases : the pairing constraint is not fulfilled. I have tried to modify the 'ensure pairable' pass (the pass undoing some of the coalescer's work) to always insert register copies for instructions with the pairable constraint, instead of being smart and

Hi Arnaud, I'm glad to hear that your test case is working. I however still get my wrong allocation in some non trivial cases : the > pairing constraint is not fulfilled. > > I have tried to modify the 'ensure pairable' pass (the pass undoing some > of the coalescer's work) to always insert register copies for > instructions with the pairable constraint, instead of

Hi Arnaud, Apologies for the delayed reply. Thank you for the excellent test case - it exposed a subtle bug in the colorability heuristic. This has been fixed in r153958. In case you are curious, the bug was as follows: the PBQP solver applies applies a simplification step to each matrix. When all elements of a matrix row or column are equal, the value for those elements is "pushed

Hi Lang, Thanks a lot for taking time to look into this. I will test the fix soon and let you know the results. Cheers, -- Arnaud de Grandmaison On Tuesday, April 03, 2012 17:30:33 Lang Hames wrote: > Hi Arnaud, > > Apologies for the delayed reply. > > Thank you for the excellent test case - it exposed a subtle bug in the > colorability heuristic. This has been fixed in

Hi Jakob, > Out of curiosity, how are you dealing with live range splitting and > coalescing in PBQP? I know you added the LoopSplitter pass. > > For linear scan in LLVM we are going in the direction of aggressive > coalescing before allocation, and on-demand splitting during allocation. > > I know that other allocators use no early coalescing, and coalesce during >

Hi Carlos, Jakob, The PBQP allocator was designed to support a very wide range of constraints, and can handle something like this easily. Say you have 4 of these orX/irX registers, then for any pair of virtual registers used in such an add instruction you would add the following constraint matrix to the PBQP instance: [ 0 inf inf inf ] [ inf 0 inf inf ] [ inf inf 0 inf ] [ inf inf inf 0

Hi Lang, Thanks for your inputs on the problem. I was just curious to know if you got any opportunity to work on the solution for this. Regards Sachin > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Sachin.Punyani at microchip.com > Sent: Tuesday, November 17, 2009 12:00 PM > Subject: Re: [LLVMdev] Crash

Thanks Lang! I think we can use linear scan as work around for short term. Thanks for your help. Regards Sachin > -----Original Message----- > From: Lang Hames [mailto:lhames at gmail.com] > Sent: Sunday, November 15, 2009 10:08 AM > To: Sachin Punyani - I00202 > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Crash in PBQP register allocator > > Hi Sachin, >

Hi Sachin, Yes. Bernhard Scholz and I have just discussed a fix for this. I hope to commit it in the next few days. I will let you know as soon as it goes in to the mainline. Regards, Lang. On Tue, Dec 15, 2009 at 5:34 PM, <Sachin.Punyani at microchip.com> wrote: > Hi Lang, > > Thanks for your inputs on the problem. I was just curious to know if you > got any opportunity to

Hi Arnaud, LiveInterval::markNotSpillable() sets the live interval's spill weight to infinity. For well-formed PBQP graphs (i.e. ones that have some finite-cost solution), PBQP should never chose to spill such an interval. The two possibilities for this crash are that the input graph has no finite-cost solution, or that you've exposed a bug in the PBQP solver. >From memory your target