[llvm-commits] [llvm] r73892 - in /llvm/trunk: include/llvm/Analysis/ScalarEvolution.h include/llvm/Analysis/ScalarEvolutionExpressions.h lib/Analysis/ScalarEvolution.cpp

[Dan Gohman]

On Jun 22, 2009, at 11:36 AM, Török Edwin wrote:


> On 2009-06-22 21:25, Owen Anderson wrote:
>
>> Author: resistor
>>
>> Date: Mon Jun 22 13:25:46 2009
>>
>> New Revision: 73892
>>
>>
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=73892&view=rev
>>
>> Log:
>>
>> Banish global state from ScalarEvolution!  SCEV uniquing is now  
>> done by tables attached to the ScalarEvolution pass.
>>
>> This also throws out the SCEV reference counting scheme, as the the  
>> SCEVs now have a lifetime controlled by the
>>
>> ScalarEvolution pass.
>>
>>
>>
>> Note that SCEVHandle is now a no-op, and will be remove in a future  
>> commit.
>>
>>
>>
>
> Hi Owen,
>
> What if somebody wants to do interprocedural analysis using SCEV
> expressions?

ScalarEvolution is a FunctionPass only because the PassManager
framework doesn't have anything that fits its needs better.
There's nothing Function-oriented about it.

ScalarEvolution could easily be a ModulePass, except that
JIT codegen wouldn't like it, and that it depends on LoopInfo,
which is a FunctionPass. LoopInfo itself could be a ModulePass,
except it depends on DominatorTree, which, finally, is actually
fairly Function-oriented.

One option might be to split ScalarEvolution into a base
ScalarEvolution class that manages SCEV objects and does all the
analysis, and a separate ScalarEvolutionFunctionPass class which
inherits from FunctionPass and exposes ScalarEvolution functionality.
Then, as long as there's a way to make it use on-the-fly passes to
get at LoopInfo and/or DominatorTree, there could be a
ScalarEvolutionModulePass.

> Will there be a way to clone SCEV* objects, so that they can live  
> longer
> than the current function being analyzed?

SCEV objects are uniquified so that they can be compared by pointer.

Dan