similar to: [LLVMdev] Supporting Complex Register Allocation Constraints (PBQP Allocator Status Update)

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 >

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

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

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

On Jun 6, 2011, at 7:07 AM, Arnaud Allard de Grandmaison wrote: > Hi All, > > My target has some instructions requiring register pairs. I decided to give a try to the PBQP allocator : it is working fine in 99% of the cases, but I am stumbling on the following issue. > > Instruction ‘MPQD’ takes 3 register operands inputs, with the constraint that operands 0 and 2 must be

Hi All, My target has some instructions requiring register pairs. I decided to give a try to the PBQP allocator : it is working fine in 99% of the cases, but I am stumbling on the following issue. Instruction 'MPQD' takes 3 register operands inputs, with the constraint that operands 0 and 2 must be consecutive registers. Operand 1 has no particular constraint. It has no output register.

Hi Jakob, The PBQP allocator should have no problem representing this. Between each pair of address/modification registers that are used together in a post-modification instruction you'll need to add the following cost matrix: sp r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 m0 0 0 0 0 0 i

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 All, I finally had a chance to get back to my pbqp trials, now using the 3.0 release. I still hit the same assert : "Attempting to spill already spilled value." This is triggered because in RegAllocPBQP::mapPBQPToRegAlloc, a vreg node is either : - a physical register (problem.isPRegOption(vreg, alloc)), - or a spill (problem.isSpillOption(vreg, alloc)) The problem is that pass

Hi Lang, > From memory your target is not public, so I won't be able to reproduce > the crash myself. Is that correct? Correct. > If that's the case, I could add functionality to dump the PBQP graphs > during allocation. I think they should give me enough information to > debug the issue. Would you be able to share the PBQP graphs? I can share the pbqp graph if you send

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

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. Im currently investigating LLVM's implementation of PBQP as a part of a bachelors thesis im doing on register allocation for regular architectures. In particullar, im looking at the possibility for improving the spill rate of PBQP for a particular DSP architecture, by using register pairing. >From reading the source code of lib/CodeGen/RegAllocPBQP.cpp i conclude that support for

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 Arnaud, The patch looks good. I've committed it in r133249. > > > I noticed an unexpected --- to me at least --- behaviour of the allocator. > > I have some instructions using 2 pairs of registers, say “mpra R_x, R_x+1, > R_y, R_y+1”, and setting the pairing constraints R_x -> R_x+1 and R_y -> > R_y+1 could silently produce wrong code like “mpra %R0, %R2, %R1,

Hi Lang, > Hmm. Let me make sure I'm reading this right. The constraints are that: > a) All four operands have distinct registers. > b) The first two are in a consecutive pair (second > first) > c) The second two are in a consecutive pair (fourth > third) Constraints b & c are OK, but a is too strict : "mpra %R0, %R1, %R0, %R1" is OK. But I though, may be

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: