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

[Török Edwin]

On 2009-06-23 00:26, Dan Gohman wrote:
> 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.
>   

I was experimenting with an interprocedural SCEV analysis, and it seemed
to mostly work, as long as:
 - I explicitly incremented the refcount to make sure its not going away
next time SCEV is rerun (adding SCEVHandle to a vector in my class took
care of this)
 - Make sure there are no stale references in SCEV, for example because
LoopInfo was rerun, and SCEV wasn't yet. This was mostly taken care of
by the releaseMemory() call
on each runFunction()
 - Doing operations on a SCEVHandle obtained from a previous SCEV run
was kind of tricky, since SCEV could easily get confused that I was
trying to do operations
on something from a previous run

To sum up, before the removal of SCEVHandle doing interprocedural
analysis with SCEV wasn't easy, and it isn't any easier/harder after the
removal of SCEVHandle.

I would certainly welcome an easier way to do IPA with SCEVs, but I
don't know what the solution for that would be.
Having SCEV be a ModulePass would probably solve my problems, but would
create problems for those who want to use SCEV from a functionpass, AFAIK
mixing modulepasses with functionpasses is not very efficient.

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

Indeed, cloning doesn't make sense then.

Best regards,
--Edwin