search for: coalescefunction

...oalescing-specific at the moment. If this changes in the future we can break it out. I'll keep it in RegisterCoalecer.h. > 5. > + /// Run the coalescer on this function, providing interference > + /// data to query. Return whether we removed any copies. > + virtual bool coalesceFunction(MachineFunction &mf, > InterferenceData &ifd) = 0; > > 80 col violation. Ok. > 6. > + /// doWork - The main coalescing algorithm. Return whether any > + /// copies were coalesced. > + bool doWork(MachineFunction &mf); > > Please rename it to someth...

...d prefer a name like isLegalToCoalesce over okToCoalesce. 4. Is it necessary to separate class InterferenceData out from RegisterCoalescer.h? 5. + /// Run the coalescer on this function, providing interference + /// data to query. Return whether we removed any copies. + virtual bool coalesceFunction(MachineFunction &mf, InterferenceData &ifd) = 0; 80 col violation. 6. + /// doWork - The main coalescing algorithm. Return whether any + /// copies were coalesced. + bool doWork(MachineFunction &mf); Please rename it to something like performCoalescing. Also, is this de...

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

...d 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 great state of flux and it was difficult to track. It will be a bit of work to get it all up-to-date for merging. Evan is right that coalesceFunction is the primary interface to invoke the coalescer. The iterative coalescer I wrote implements that function. The iterative coalescer is also a FunctionPass which does nothing. It's simply there to fulfill the requirement that the register allocator depends on a coalescer. This way I coul...

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

...ent. > If this changes in the future we can break it out. I'll keep it in > RegisterCoalecer.h. > >> 5. >> + /// Run the coalescer on this function, providing interference >> + /// data to query. Return whether we removed any copies. >> + virtual bool coalesceFunction(MachineFunction &mf, >> InterferenceData &ifd) = 0; >> >> 80 col violation. > > Ok. > >> 6. >> + /// doWork - The main coalescing algorithm. Return whether any >> + /// copies were coalesced. >> + bool doWork(MachineFunction &...

...how > PassManager works and providing the capability of constructing > hierarchies > of PassManagers. Ok. I am willing to be flexible if it helps moving things along. Just make sure you pick decorative names for the entry points. For example, rather than invoke(), use something like CoalesceFunction(). And please try to limit the number of such entries. > > I'm still working out getting things to build, etc. and will post a > patch when > I've got through all that. But does this sound like something > closer to what > we want? Ok. Thanks! Evan > >...

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