search for: coalesced

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

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 user-specified register coalescers, similar

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

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

...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. > + vir...

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, then it will be very

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

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

...ot; because not every allocator could answer it. The coalesceThisCopy interface is there for similar reasons. Some coalescing algorithms (Briggs' conservative coalescing is a good example) examine the interference graph and apply heuristics based on the degree of the neighbors of nodes being coalesced. Your utility class could provide interfaces to make more fine-grained queries, but as noted above, it seems a bit harder as various register allocators may use very difference representations. So coalesceThisCopy is certainly a compromise. It does move some of the decision-making for coales...

...:-) > > The coalesceThisCopy interface is there for similar reasons. Some > coalescing > algorithms (Briggs' conservative coalescing is a good example) > examine the > interference graph and apply heuristics based on the degree of the > neighbors > of nodes being coalesced. Your utility class could provide > interfaces to make > more fine-grained queries, but as noted above, it seems a bit > harder as > various register allocators may use very difference > representations. So > coalesceThisCopy is certainly a compromise. It does move some...

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

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

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. createRegisterAllocator() is

...> > 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 because if it does the data structures will be inconsistent. > > Ok. But that means this method doesn't belong to the InterferenceData > class. Shouldn't the alloca...

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

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

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 =

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 >

...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(co...

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