similar to: [LLVMdev] pbqp register allocator-need help

On Sun, Aug 11, 2013 at 12:36 AM, Smriti Jaiswal <jaiswal.smriti at gmail.com>wrote: > Hello Sir, > > Im trying to test run pbqp register allocator for small C programs. > > by > > llc -regalloc=pbqp -debug <bitcode of the file> > > It is giving me segmentation fault for even very simple programs having > loops or if statements. > Please tell me where

The simple C code on which im running the allocator is attached. And these are the set of commands. I dont understand ..guess i might be doing something very silly. Please help *Commands:* clang -emit-llvm -c test.c -o test.bc opt -mem2reg test.bc -o testssa.bc llc -regalloc=pbqp testssa.bc On Mon, Aug 12, 2013 at 7:59 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > >

On Sep 20, 2010, at 7:53 AM, Lang Hames wrote: > 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. Thanks, Lang! Out of curiosity, how are you dealing with live range splitting and coalescing in PBQP?

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, Please see the two ".ll' files attached. Command line used llc -march=pic16 -pre-RA-sched=list-burr -regalloc=pbqp new.obc The above test case crashes only when I use the combination of list-burr scheduler and pbqp register allocator. If any of them (scheduler or register allocator) is replaced with some alternate then I don't see the crash. I could not figure

This looks like a bug in the PBQP solver. I'm currently investigating. Cheers, Lang. On Thu, Nov 12, 2009 at 12:46 AM, <Sachin.Punyani at microchip.com> wrote: > Hi, > > > > Please see the two “.ll’ files attached. > > > > Command line used > > llc –march=pic16  –pre-RA-sched=list-burr –regalloc=pbqp new.obc > > > > The above test case

Hi all, I was wondering about whether the PBQP register allocator is likely to be maintained in the future. It's proving to be a nice way to encode some instruction encoding constraints for an out-of-tree backend we have, but there's concern about it being abandoned or bitrotting in the future. Also, if PBQP is likely to lapse out of regular maintenance in the future, is there a simple

Hi Sachin, Confirmed: This is being caused by a subtle issue in the heuristic PBQP solver. Specifically: R1/R2 reductions as currently implemented can, on rare occasions, lead to the heuristic solver failing to find a finite cost solution, even though one exists. The infinite cost solution will always be in violation of some rule of register allocation (failing to handle an interference, or

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

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 Duncan, >> New PBQP solver. > > nice! Any chance of a quick summary of the state of the pbqp allocator and > who might want to use it? Sure. Here's an update, broken into three handy sections: Summary for LLVM users: --- PBQP is a heavyweight register allocator. A quick, not-at-all scientific look at SPEC2006 shows that compiling with -regalloc=pbqp increased runtime

> > * This claim is only partially tested, but I'm running the allocator right > now with the base constraints plus an extension which adds coalescing costs > and it's just passed CINT2006 without error. Not bad given that the > coalescing extension only took a couple of hours to write > Following up on this footnote - The PBQPBuilderWithCoalescing builder is now in the

Hi Sachin, llvm-dev, I've just committed a new PBQP solver which, among other things, should take care of this bug. Please let me know how it works out for you. Cheers, Lang. On Tue, Dec 15, 2009 at 5:54 PM, Lang Hames <lhames at gmail.com> wrote: > 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

Hi Lang, I'm surprised about the fact that you omit R1/R2 reductions in some cases. Can you give a more detailed description of the bug (e.g. a PBQP dump)? Best regards, Sebastian Lang Hames wrote: > Hi Sachin, llvm-dev, > > I've just committed a new PBQP solver which, among other things, > should take care of this bug. > > Please let me know how it works out for you.

On Sep 20, 2010, at 4:11 PM, Lang Hames wrote: > > The PBQP allocator uses the aggressive coalescer and optionally adds coalescing costs for any remaining copies to the PBQP problem (if you use -pbqp-coalescing). Unfortunately relying on PBQP's coalescing alone is not an option - the graphs coming out of PHI elimination are very large and without aggressive coalescing to bring the size

Lang Hames wrote: > Hi Sebastian, > > > We did. The success of normalization in this case depends on whether > you attempt to normalize rows first, then columns, or the other way > around. > > Currently rows are normalized first, then columns. In your example the > infinite costs are thus propagated onto element 1 of node 0, rather > than node 4, which leaves us

Hi Sebastian, It boils down to this: The previous heuristic solver could return infinite cost solutions in some rare cases (despite finite-cost solutions existing). The new solver is still heuristic, but it should always return a finite cost solution if one exists. It does this by avoiding early reduction of infinite spill cost nodes via R1 or R2. To illustrate why the early reductions can be a

Hi Sebastian, > I think the crucial point is that node4 isn't aware of its own > restriction (after the first R2 reduction). > If you normalize the new matrix (shifting costs in the adjacent vector > until each row/column has minima 0) after a R2 reduction of a node with > infinite spill cost the problem should disappear. <snip> > Did you consider this option? We