search for: coalescer

...rks 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 > allocator about which copies it should remove. For example, Briggs' > conservative coalescer will not remove copies that could potentially cause > spills. Onl...

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

...Coloring algorithm,. It's not easy to accomplish within the LLVM framework. I've made a number of structural changes to our code here and it's in a bit of a state of bitrot due to upstream changes we haven't merged in yet. I got some of this work merged upstream in the RegisterCoalescer and RegallocQuery interfaces. RegallocQuery is supposed to be an opaque communication conduit between register allocators and coalescers such that the allocator can update the coalescer when it makes changes and vice versa. When I did the full implementation I found I had to make more changes...

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

...// 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(const MachineInstr &inst) const { > + return(true); > + } > > I think we discussed this early but please remind me. Why is this > necessary? Why isn't interfere() sufficient test? Also, I would prefer > a name like isLegalToCoal...

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 allocator's algorithm, or even &g...

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

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

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

...umptions >> 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(const MachineInstr &inst) const { >> + return(true); >> + } >> >> I think we discussed this early but please remind me. Why is this >> necessary? Why isn't interfere() sufficient test? Also, I would >> pr...

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

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

...; > 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 allocator query the coalescer instead? No, it's the other way around. The coalescer...

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

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

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 > sharing work to be done with this, but I want to get...

...t 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(const MachineInstr &inst) const { + return(true); + } I think we discussed this early but please remind me. Why is this necessary? Why isn't interfere() sufficient test? Also, I would prefer a name like isLegalToCoalesce over okToCoalesce. 4. Is...

...; = COPY %vreg11 , %vreg11 and %vreg2 could have been coalesced (%vreg11 is unused outside this block) My question is how to best handle this. * Seems to me probably best to handle this pre-ra if possible, even though cases like this may be handled later. * Pre-RA mischeduler is run after the coalescer, so that's not going to work. thanks for any help, Jonas