search for: coalescers

...his copy potentially cause a spill?" > > AI think all this will require is new RegisterCoalescer and RegisterAllocator > interface classes that can be multiply-inherited (with MachineFunctionPass) > by the various implementations. > > It's not totally clear to me whether coalescers should even inherit from > MachineFunctionPass as they are really invoked by the register allocator, > not PassManager. But then again, I can imagine some coalescers (like the > existing one) being independent enough to run on their own at any time. > Opinions on this are welcome. I t...

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

...e 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 to RegallocQuery. I have not pushed those upstream for various reasons, including that at the time the register coalescing code was in a...

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

On Monday 27 August 2007 15:13, Evan Cheng wrote: > 1. typedef std::set<const LiveInterval *> IntervalSet; > Please use SmallPtrSet instead. Ok. > 2. > + virtual void mergeIntervals(const LiveInterval &a, > + const LiveInterval &b, > + const MachineInstr &copy) {}; > > I find the name

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

...lly understand what you're proposing. The reason I went with the AliasAnalysis-like construct is that I envisioned a "-coalescer=<type>" user option, similar to how alias analysis and register allocation works. Somehow we have to make that option work with independent register coalescers (those derived from MachineFunctionPass or equivalents that can run through the PassManager) and those that are tied to some abstract register allocation algorithm. A coalescer that runs in conjunction with an allocator need not be tied to a particular implementation of register allocation. For e...

...you're proposing. The reason I > went with the AliasAnalysis-like construct is that I envisioned a > "-coalescer=<type>" user option, similar to how alias analysis and > register allocation works. Somehow we have to make that option > work with independent register coalescers (those derived from > MachineFunctionPass or equivalents that can run through the > PassManager) and those that are tied to some abstract register > allocation algorithm. A coalescer that runs in conjunction with an > allocator need not be tied to a particular implementation of registe...

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.

..., "will coalescing this copy potentially cause a spill?" AI think all this will require is new RegisterCoalescer and RegisterAllocator interface classes that can be multiply-inherited (with MachineFunctionPass) by the various implementations. It's not totally clear to me whether coalescers should even inherit from MachineFunctionPass as they are really invoked by the register allocator, not PassManager. But then again, I can imagine some coalescers (like the existing one) being independent enough to run on their own at any time. Opinions on this are welcome. Does this sound lik...

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

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

...d under +// the University of Illinois Open Source License. See LICENSE.TXT for details. +// +// ===--------------------------------------------------------------------- -===// +// +// This file contains the abstract interface for register allocators, +// allowing them to provide information to coalescers. +// +// ===--------------------------------------------------------------------- -===// + +#ifndef LLVM_CODEGEN_REGISTER_ALLOCATOR_H +#define LLVM_CODEGEN_REGISTER_ALLOCATOR_H + +#include <llvm/CodeGen/LiveInterval.h> + +namespace llvm +{ + class MachineInstruction; + + class RegisterAll...

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 you want a > third module to encapsulate it. Yes, that makes sense to me. > I don't care for a MachineFunctionPass that can b...

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

Hi David, Thanks for this patch! Some comments: 1. typedef std::set<const LiveInterval *> IntervalSet; Please use SmallPtrSet instead. 2. + virtual void mergeIntervals(const LiveInterval &a, + const LiveInterval &b, + const MachineInstr &copy) {}; I find the name misleading. It's not actually

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 // R2 = R2 + 4 The reason this wasn't coalesced, is