search for: coalesc

>> Ok, that sounds like a good plan. I'll brush up on how alias analysis >> works and work from there. > > I've been looking at this and it's become clear to me that we need some kind > of abstract coalescing interface similar to what the AliasAnalysis class > provides. I think we need the same thing for register allocators. > > LLVM's existing coalescer is very simple. It just goes and replaces every > copy it can. In general, a coalescer will want to query the register > alloc...

Here's a proposed patch for reworking register coalescing to allow pluggable coalescers. I think I've got the interfaces where I want them and am reasonably sure I've squashed most of the bugs. I'm still doing some testing and want to get through a whole regimen before committing. As a reminder, this patch has several goals: - Allow us...

On Friday 09 January 2009 03:36, Roman Levenstein wrote: > Hi, > > I'm implementing some variations of graph-coloring register allocators for > LLVM. Many of them perform their phases (e.g. coalescing, graph > simplification, spilling, color selection) in an iterative way. Since > LLVM provides an implementation of the coalescing in the > SimpleRegisterCoalescing class already, I would like to reuse it (even > though I could of course create my own coalescing implementation). But...

Hi, I'm implementing some variations of graph-coloring register allocators for LLVM. Many of them perform their phases (e.g. coalescing, graph simplification, spilling, color selection) in an iterative way. Since LLVM provides an implementation of the coalescing in the SimpleRegisterCoalescing class already, I would like to reuse it (even though I could of course create my own coalescing implementation). But this class is a Mac...

...h to reflect the merge. > Please choose a more descriptive name. Yes it's for updating the graph. I'll pick a better name, but I don't want it to be graph-specific. > 3. > > + /// Allow the register allocator to communicate when it doesn't > + /// want a copy coalesced. This may be due to assumptions made by > + /// the allocator about various invariants and so this question is > + /// a matter of legality, not performance. Performance decisions > + /// about which copies to coalesce should be made by the > + /// coalescer. > + v...

On Mon, Jul 10, 2023 at 12:20:01PM +0300, Gavin Li wrote: > Currently, coalescing parameters are grouped for all transmit and receive > virtqueues. This patch series add support to set or get the parameters for > a specified virtqueue. > > When the traffic between virtqueues is unbalanced, for example, one virtqueue > is busy and another virtqueue is idle, the...

On Monday 09 July 2007 16:49, Reid Spencer wrote: > The only thing that comes to mind is that creating and running the > coalescer are separate operations so you might want to do the creation > of it in alias analysis style. Then, the allocator can a) determine if a > coalescer was created, b) obtain the coalescer that was created, if any, > and c) run it at the right time for the allocator's algorithm, or even...

On Thu, 13 Jul 2023 07:40:12 -0400, "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Mon, Jul 10, 2023 at 12:20:01PM +0300, Gavin Li wrote: > > Currently, coalescing parameters are grouped for all transmit and receive > > virtqueues. This patch series add support to set or get the parameters for > > a specified virtqueue. > > > > When the traffic between virtqueues is unbalanced, for example, one virtqueue > > is busy and anothe...

On Monday 16 July 2007 18:19, Evan Cheng wrote: > Sorry I should have replied earlier. I really don't like this dual > interface approach. To me, this muddles things without offering any > real useful new functionalities. Ok. See below for the rationale. > IMHO, if a register coalescer is tied to a particular allocator. Then > either it should simply belong to that allocator or that we have to > allow the allocator to act as a pass manager itself, i.e. it can > control what passes to run as part the allocating process. I don't > know if the pass manager allows t...

...Evan Cheng wrote: > >> Sorry I should have replied earlier. I really don't like this dual >> interface approach. To me, this muddles things without offering any >> real useful new functionalities. > > Ok. See below for the rationale. > >> IMHO, if a register coalescer is tied to a particular allocator. Then >> either it should simply belong to that allocator or that we have to >> allow the allocator to act as a pass manager itself, i.e. it can >> control what passes to run as part the allocating process. I don't >> know if the pass...

On Aug 27, 2007, at 2:04 PM, David Greene wrote: > >> 3. >> >> + /// Allow the register allocator to communicate when it doesn't >> + /// want a copy coalesced. This may be due to assumptions >> made by >> + /// the allocator about various invariants and so this >> question is >> + /// a matter of legality, not performance. Performance >> decisions >> + /// about which copies to coalesce should be mad...

On Monday 09 July 2007 17:07, David Greene wrote: > On Monday 09 July 2007 16:49, Reid Spencer wrote: > > The only thing that comes to mind is that creating and running the > > coalescer are separate operations so you might want to do the creation > > of it in alias analysis style. Then, the allocator can a) determine if a > > coalescer was created, b) obtain the coalescer that was created, if any, > > and c) run it at the right time for the allocator's algo...

Ok, I'm at a point now where I can implement plyggable register coalescers as we originally wanted when I started the refactoring work. I'm in the midst of finishing up an implementation following the model of how register allocators are selected. Thgere may be some more refactoring/code sharing work to be done with this, but I want to get it working first. crea...

On Monday 27 August 2007 19:02, Evan Cheng wrote: > > interfere() isn't sufficient because the allocation algorithm may > > place other > > constraints on coalescing. George and Appel's iterated register > > coalescing > > is a prime example. It wants to "freeze" copies that should not be > > coalesced > > because doing so might cause spilling. You don't want the coalescer > > touching > > these becaus...

Hi David, Sorry I should have replied earlier. I really don't like this dual interface approach. To me, this muddles things without offering any real useful new functionalities. IMHO, if a register coalescer is tied to a particular allocator. Then either it should simply belong to that allocator or that we have to allow the allocator to act as a pass manager itself, i.e. it can control what passes to run as part the allocating process. I don't know if the pass manager allows that function...

On Tuesday 17 July 2007 13:06, Evan Cheng wrote: > > These two requirements led to the abstract RegisterCoalescer > > interface in the patch. This is the interface that register > > allocators > > know about. Likewise, coalescers need an abstract interface to > > register allocators to ask questions and do other things. > > If the two modules need to share information. I think...

Chris Lattner wrote: > On Thu, 12 Apr 2007, Fernando Magno Quintao Pereira wrote: >>> I'm definitely interested in improving coalescing and it sounds like >>> this would fall under that work. Do you have references to papers >>> that talk about the various algorithms? >> Some suggestions: >> >> @InProceedings{Budimlic02, >> AUTHOR = {Zoran Budimlic and Keith D. Cooper and Timothy...

Hi David, On Mon, 2007-07-09 at 16:32 -0500, David Greene wrote: > Ok, I'm at a point now where I can implement plyggable register coalescers as > we originally wanted when I started the refactoring work. > > I'm in the midst of finishing up an implementation following the model of how > register allocators are selected. Thgere may be some more refactoring/code > sharing work to be done with this, but I want to ge...

...mp;copy) {}; I find the name misleading. It's not actually performing the merging, right? It's updating the interference graph to reflect the merge. Please choose a more descriptive name. 3. + /// Allow the register allocator to communicate when it doesn't + /// want a copy coalesced. This may be due to assumptions made by + /// the allocator about various invariants and so this question is + /// a matter of legality, not performance. Performance decisions + /// about which copies to coalesce should be made by the + /// coalescer. + virtual bool okToCoalesce(...

Hi, I am seeing cases of poorly coalesced IV updates on SystemZ: In the final IR, it is obvious that %R4D<def> = LA %R2D<kill>, 4, %noreg // R4 = R2 + 4 %R2D<def> = LGR %R4D<kill> // R2 = R4 could be optimized to -> %R2D<def> = LA %R2D<kill>, 4, %noreg /...