llvm dev - May 2007 - [LLVMdev] alias information on machine instructions

Chris Lattner wrote:
> There are a couple of ways to do this.  Is your scheduler a prepass
> scheduler (before regalloc) or a post-pass scheduler (after regalloc)? 
it is a post-pass scheduler, which operates on MachineInstrs. we need to
run it after register allocation to hide latencies of spill code,
prolog, and epilog.
> If you want to extract maximal parallelism, I assume you want a prepass
> scheduler.  In that case, you should look into the SelectionDAG based
> schedulers, which do have alias information on them.
i had a look at the SelectionDAG based schedulers. it seems that
aliasing loads/stores are chained together by the DAGCombiner. after
scheduling, when the MachineInstrs are created, the alias information
cannot be used anymore in the current framework. is this correct?

i don't think that it is a good idea to do alias analysis on
MachineInstrs, thus i would like to preserve the alias information, and
annotate the MachineInstrs explicitly. however, this information might
be invalidated by subsequent passes.

currently, our backend does not emit any additional loads/stores execpt
for spill code, prolog and epilog. thus this approach would work (at
least for now).

do you have any ideas for a better solution?

florian

On Fri, 4 May 2007, Florian Brandner wrote:
> Chris Lattner wrote:
>> There are a couple of ways to do this.  Is your scheduler a prepass
>> scheduler (before regalloc) or a post-pass scheduler (after regalloc)?
>
> it is a post-pass scheduler, which operates on MachineInstrs. we need to
> run it after register allocation to hide latencies of spill code,
> prolog, and epilog.
ok.
>> If you want to extract maximal parallelism, I assume you want a prepass
>> scheduler.  In that case, you should look into the SelectionDAG based
>> schedulers, which do have alias information on them.
>
> i had a look at the SelectionDAG based schedulers. it seems that
> aliasing loads/stores are chained together by the DAGCombiner. after
> scheduling, when the MachineInstrs are created, the alias information
> cannot be used anymore in the current framework. is this correct?
Right.  The original Value*'s are preserved in the DAG, but dropped when 
MachineInstrs are created.  We could add a machineoperand to capture this 
Value* if desired.
> i don't think that it is a good idea to do alias analysis on
> MachineInstrs, thus i would like to preserve the alias information, and
> annotate the MachineInstrs explicitly. however, this information might
> be invalidated by subsequent passes.
Right, it would have to be added as a Value* operand to MachineInstr. 
This would not be invalidated by later passes, they would just ignore the 
field.  Targets would have to be updated though, as certain pieces of code 
"know" about the expected operands.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner
wrote:
> On Fri, 4 May 2007, Florian Brandner wrote:
> > i had a look at the SelectionDAG based schedulers. it seems that
> > aliasing loads/stores are chained together by the DAGCombiner. after
> > scheduling, when the MachineInstrs are created, the alias information
> > cannot be used anymore in the current framework. is this correct?
> 
> Right.  The original Value*'s are preserved in the DAG, but dropped
when
> MachineInstrs are created.  We could add a machineoperand to capture this 
> Value* if desired.
Another benefit of keeping the original Value*'s (and offsets) around is it
would provide more information that could be used for verbose asm output
and MachineInstr-level dumps, which would be quite nice.

Dan

-- 
Dan Gohman, Cray Inc.