similar to: [LLVMdev] Pluggable Register Coalescers

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 >

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 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, 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 Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > I think the coalescer should be flexible enough to be run independent of > the register allocator. For example, you may want to expose the copies > induced by transforming out of SSA to the scheduler. If the scheduler is > run before register allocation, then you would want the coalescing to > happen before as well. I

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

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

On Tuesday 17 July 2007 14:21, David Greene wrote: > > I don't care for a MachineFunctionPass that can be directly called. I > > think it's a very good idea to keep the coalescers independent from > > the allocators. If that's desired, we should enhance passmanager so > > each allocator can run some sub-passes as part of the allocation > > pass. > >

On Friday 13 July 2007 13:32, David A. Greene wrote: > On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > > Could it be possible for there to be a harness type interface that > > would allow coalescers that support both modes to be hooked into the > > pass registration, and those that depend on the allocator not be > > registered as passes? > > I have a

On Jul 17, 2007, at 8:40 AM, David Greene wrote: > 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

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 Jul 16, 2007, at 9:12 AM, David Greene wrote: > On Friday 13 July 2007 13:32, David A. Greene wrote: >> On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: >>> Could it be possible for there to be a harness type interface that >>> would allow coalescers that support both modes to be hooked into the >>> pass registration, and those that depend on the

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > Could it be possible for there to be a harness type interface that > would allow coalescers that support both modes to be hooked into the > pass registration, and those that depend on the allocator not be > registered as passes? I have a patch for this kind of thing attached. Please take a look and let me know if it looks

On Jul 17, 2007, at 8:49 PM, David A. Greene wrote: > On Tuesday 17 July 2007 14:21, David Greene wrote: > >>> I don't care for a MachineFunctionPass that can be directly >>> called. I >>> think it's a very good idea to keep the coalescers independent from >>> the allocators. If that's desired, we should enhance passmanager so >>>

On Monday 16 July 2007 18:20, Evan Cheng wrote: > > Does the current implementation follow a published algorithm? If > > so, do we > > have a pointer to it? The comments are rather sparse and it's > > difficult to > > figure out what's going on at times. > > I don't know. I suspect not. I agree the current implementation is a > bit of a

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

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.

Hi David, Just as an idea, you could try to use a coloring register allocator submitted by Bill Wendling some time ago on the mailing list? See this thread for more information http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-April/008489.html This allocator is already implemented using LLVM and could be probably useful for testing your new infrastructure and refactored interfaces. At least