[LLVMdev] HazardRecognizer and RegisterAllocation

[David Greene]

On Monday 19 January 2009 19:47, Dan Gohman wrote:

> >  Can they be used in conjunction with
> > MemoryDependenceAnalysis?  e.g. can we write a MachineInstructions-
> > based
> > memory dependence analysis that uses MachineMemoryOperands?
>
> Right, the existing MemoryDependenceAnalysis works in terms of
> LLVM-IR-level Instructions, but yes, it would be possible to
> implement the same thing for MachineInstrs, using AliasAnalysis
> queries from MachineMemOperands. As of this writing I'm not
> prepared to guess whether this would be a good idea :-).

Sure.  It seems fairly straightforward though.  Heck, it might even be 
possible to take MemoryDependenceAnalysis and turn it into generic code that 
could operate on Instructions or MachineMemOperands.

> >> 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?
>
> A possible vision is that SelectionDAGBuild could use
> MemoryDependenceAnalysis when building the initial SelectionDAG.
> It's walking the IR-level Instructions, so it can use any
> IR-level analysis. I haven't yet looked into this in detail.
> A significant question is whether non-local dependencies are
> important; some day we may extend SelectionDAGs to handle
> more than one block at a time.

I should think non-local dependencies would be important.  We have a number of 
machine code passes that work globally.

> > 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.
>
> This is where PseudoSourceValues come in. There are pseudo-values
> representing the stack, constants area, GOT, and other memory
> locations that aren't represented at the LLVM-IR level.

Ok, that's good.  But what happens if some codegen pass deletes a memory 
instruction (or a Value or whatever) and recreates it elsewhere.  Presumably 
the dependence information would be lost.  How would we re-generate it.

> I think the biggest challenge here is finding a design that
> is reasonably efficient in terms of compile time and space while
> still providing useful information.

Isn't that the definition of compiler development?  :)

                                       -Dave