search for: interferencedata

...e" 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 needs to decide whether it can coalesce something. It must ask the allocator if it's ok. This is part of InterferenceData to decouple the coalescer from the allocator so the...

...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. > 4. Is it necessary to separate class InterferenceData out from > RegisterCoalescer.h? Good point. Originally I had thought that InterferenceData might be more general-purpose but it is rather coalescing-specific at the moment. If this changes in the future we can break it out. I'll keep it in RegisterCoalecer.h. > 5. > + /// Run t...

...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? Thanks, Evan > > >> 4. Is it necessary to separate class InterferenceData out from >> RegisterCoalescer.h? > > Good point. Originally I had thought that InterferenceData might be > more general-purpose...

...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 needs to decide > whether it can > coalesce something. It must ask the allocator if it's ok. > > This is part of InterferenceData to decouple the c...

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

...or analysis group implementation selection by the pass managers (all coalescers must have a common interface to be part of the analysis group). The patch realizes the second goal through this common interface, which has methods for invoking the coalescer, possibly repeatedly. There is an abstract InterferenceData interface for the register allocator to provide information to the coalescer in an opaque manner. I've implemented these interfaces in a compiler with the current linear scan allocator as well as a graph coloring allocator, with the current coalescer as well as one based on George and Appel&...

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: