similar to: [LLVMdev] [patch] Pluggable Coalescers

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

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

I incorporated Evan's suggested changes and testing seems to go well. Ok to commit? -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: pluggable_coalescer.patch Type: text/x-diff Size: 14338 bytes Desc: not available URL:

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 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 Aug 28, 2007, at 8:59 AM, David Greene wrote: > 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

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

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 >

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

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

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

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 Monday 20 August 2007 15:58, David A. Greene wrote: > Here's a proposed patch for reworking register coalescing to allow > pluggable coalescers. No comments? Or is everyone taking vacation before the fall? :) -Dave

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 17, 2007, at 12:21 PM, David Greene wrote: > >> Are you designing the coalescer so it always run before >> allocation? If so, >> please keep it simple. :-) > > Believe me, I'm trying to keep it as simple as possible. The > coalescer I'm > working on doesn't run "before" allocation. It runs in conjunction > with it. >