Andrew Lenharth wrote:> On Fri, 2005-03-18 at 05:04 +0900, Duraid Madina wrote: >> - No varargs > > What are your issues here? Or are they simply at the "not implemented > so I don't know" stage?The two bugs I mentioned (no varargs, no alloca) are pretty much two sides of the same coin: I'm ignoring the IA64 stack frame layout (for no good reason), so these don't work. Actually, varargs seems particularly simple on IA64, so I'll swat these two bugs pretty soon.> Namely, I am working on some varargs changes > that may or may not be applicable to you.Hmm. :)>> - 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. Duraid
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. :( -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
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