On Monday 19 January 2009 16:42, Dan Gohman wrote:> >> Perhaps you want to do this after register allocation is done. Dan is > >> developing the post-allocation scheduler. You can try it out. > > > > Interesting. Can it already be found SVN? I will search the mail > > archive > > later, if not. > > Yes, it is in SVN. It's new, and so far it's only being used in limited > ways, and not anything like your specific problem. We don't currently > have any targets in-tree that require no-ops, so it may not address all > your needs out of the box, but patches are welcome :-).Dan, how does the scheduler handle memory dependence? I'm working on something that requires memory dependence information for MachineInstructions. -Dave
On Jan 19, 2009, at 3:38 PM, David Greene wrote:> On Monday 19 January 2009 16:42, Dan Gohman wrote: > >>>> Perhaps you want to do this after register allocation is done. >>>> Dan is >>>> developing the post-allocation scheduler. You can try it out. >>> >>> Interesting. Can it already be found SVN? I will search the mail >>> archive >>> later, if not. >> >> Yes, it is in SVN. It's new, and so far it's only being used in >> limited >> ways, and not anything like your specific problem. We don't currently >> have any targets in-tree that require no-ops, so it may not address >> all >> your needs out of the box, but patches are welcome :-). > > Dan, how does the scheduler handle memory dependence? I'm working on > something that requires memory dependence information for > MachineInstructions.At the moment, it knows simple things, like constant pool loads don't have dependencies, and references to distinct stack slots are independent, and so on. I have a few ideas for how more precise memory dependencies might be achieved. We have MachineMemOperands, which can be used to make AliasAnalysis or other LLVM-IR-level analysis queries. They need some work though; the main issue is that there are some places in codegen that don't preserve them. Another possibility is to record dependence information from the SelectionDAG in MachineInstrs somehow. We don't yet have precise memory dependencies in the SelectionDAG, but it would be good to fix that too :-). This would probably also involve AliasAnalysis queries from codegen, possibly going though the MemoryDependenceAnalysis interface. Dan
On Monday 19 January 2009 18:21, Dan Gohman wrote:> > Dan, how does the scheduler handle memory dependence? I'm working on > > something that requires memory dependence information for > > MachineInstructions. > > At the moment, it knows simple things, like constant pool loads > don't have dependencies, and references to distinct stack slots are > independent, and so on.Ok.> I have a few ideas for how more precise memory dependencies might be > achieved. > > We have MachineMemOperands, which can be used to make AliasAnalysis > or other LLVM-IR-level analysis queries. They need some work though; > the main issue is that there are some places in codegen that don't > preserve them.Where are those places? Can they be used in conjunction with MemoryDependenceAnalysis? e.g. can we write a MachineInstructions-based memory dependence analysis that uses MachineMemoryOperands?> Another possibility is to record dependence information from the > SelectionDAG in MachineInstrs somehow. We don't yet have precise > memory dependencies in the SelectionDAG, but it would be good to > fix that too :-).Agreed.> This would probably also involve AliasAnalysis queries from codegen, > possibly going though the MemoryDependenceAnalysis interface.Do you have a vision for how this might work? Wouldn't we need a new MachineFunctionPass to essentially do the same thing as MemoryDependenceAnalysis? I don't think it's sufficient to just preserve the information we had from Instructions. Codegen might introduce new memory operations after lowering (spilling, for example). Some of these might be easily analyzable (spills) but others might not be. But maybe we don't need to worry about that right now. As I think about the problem I'm working on, "merely" preserving dependence information from Instructions would help. It seems like if we can preserve that information in SelectionDAG we ought to be able to record it in MachineInstructions (or MachineMemOperands?) when lowering. Hmm...then again looking at the MachineMemOperand documentation, fixing the places that invalidate those might work well too. I'm a little wary of having the same information in two different places. -Dave