[LLVMdev] alias information on machine instructions

Dan Gohman djg at cray.com
Mon Jun 18 08:27:44 PDT 2007


On Fri, Jun 15, 2007 at 04:16:57PM +0200, Florian Brandner wrote:
> hi,
> 
> 
> Florian Brandner wrote:
> > Dan Gohman wrote:
> >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote:
> >>> 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.
> >>
> > 
> > i'll do this and post a patch, unless someone else is already working on
> > this.
> > 
> 
> i have extended the DAG instruction selector and scheduler to preserve
> Value*'s. the values are attached to machine instructions as a separate
> operand list (at least for now). for now this looks very good.

Cool!

> but i found that the alias analysis is not as good as expected. the
> problem seems to be the codegenprepare pass. GEP instructions are
> lowered to integer calculations (e.g. ptrtoint, add, inttoptr). this
> causes the (basic) alias analysis to answer MayAlias for most queries.
> 
> this is also a problem for the DAG combiner, when the
> -combiner-global-alias-analysis switch is given to llc.
> 
> any ideas how to handle this?

I don't have any that are both easy and clean :-/.

It probably wouldn't be difficult to teach the basic alias analysis how
to dig past adds and casts to find base expressions. Or, make the
CodeGenPrepare pass use getelementptrs directly instead of expanding
addressing into integer operations. Or maybe instcombine could be run
after CodeGenPrepare so it could fold the integer operations into 
getelementptrs?

I think the long-term solution is to teach the SelectionDAG framework
how to look beyond basic-block boundaries so that CodeGenPrepare doesn't
have to do this de-hoisting of addressing.

It also might make sense to write a SCEV-based AliasAnalysis some day.

Dan

-- 
Dan Gohman, Cray Inc.



More information about the llvm-dev mailing list