search for: coalescethiscopi

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

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