[LLVMdev] alias information on machine instructions

[Evan Cheng]

On Jun 18, 2007, at 8:27 AM, Dan Gohman wrote:

> 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

I think this is very much doable and would provide much immediate  
benefit. It's not a trivial task. We have to make sure DAG combiner  
and legalizer do not muck up alias information (among other challenges).


> 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.

Whole-function isel is being considered. No immediate plan yet though.

Evan

>
> It also might make sense to write a SCEV-based AliasAnalysis some day.
>
> Dan
>
> -- 
> Dan Gohman, Cray Inc.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev