[LLVMdev] new IA64 backend

[Andrew Lenharth]

On Thu, 2005-03-17 at 23:31 -0600, Chris Lattner wrote:
> On Fri, 18 Mar 2005, Duraid Madina wrote:
> >>> 	- No instruction scheduling/bundling of any sort
> >> 
> >> So this one needs to be coordinated.  Next week, I might see about
> >> adding MachineInstruction support to the SelectionDAG so you can load up
> >> a DAG post-ISel and then spit it back out scheduled.
> >
> > That would be much appreciated, particularly if it means that we can have 
> > scheduled MachineInstructions living alongside DAGs in such a way that 
> > changing the DAG (adding/removing a couple of instructions, say) doesn't 
> > _necessarily_ require rescheduling the whole function. I'm thinking of a 
> > future JIT here, where it would be nice to be able to sprinkle/reap 
> > instrumentation code over functions at high speed.
> 
> To me, I think the correct approach is to look at instruction selection in 
> terms of dag rewriting, not the current pattern-matching-and-machineinstr- 
> emission process we have now.
> 
> In particular, I think the only real way to handle X86 register pressure 
> is to produce a dag labeled by X86 opcodes, then have a register pressure 
> aware emission process (like the Goodman and Hsu approach).  If the other 
> backends worked this way, they could naturally do DAG-based scheduling as 
> well.
> 
> I guess I don't really see the point of going:
> 
> DAG ----select---> MachineInstrs -> DAG ----schedule----> Machineinstrs
> 
> When this should work:
> 
> DAG ----select---> DAG ----schedule----> MachineInstrs
> 
> This was in my plan to implement, but unfortunately I won't have time to 
> play with this for a while. :(

Right, but once the MI are RAed, you want to be able to do a post-pass
scheduling also.  So you need to be able to take a MBB and produce a
DAG.  A scheduler obviously wouldn't care how it came about having a
DAG.  And it is easier to do the lift from a MBB to a DAG than to change
the entire ISelPattern process at the moment.  Baby steps.

Andrew