[llvm-commits] value range analysis based on scalar-evolutions

Dan Gohman gohman at apple.com
Wed Jun 4 11:43:03 PDT 2008


On Jun 3, 2008, at 8:51 PM, Nick Lewycky wrote:

> Devang Patel wrote:
>>
>> Is there a reason to not make this a LoopPass ?
>
> Because then it wouldn't store Value->ConstantRange mappings for the
> whole function. There's no reason the SCEV analysis stuff couldn't  
> move
> into a LoopPass, but the mapping probably shouldn't be.

SCEV isn't conceptually a LoopPass. It's true that our current
in-tree SCEV users are all LoopPasses, but the underlying SCEV
logic isn't fundamentally single-loop-oriented or even
single-loop-nest-oriented. SCEV isn't really even a FunctionPass
either, at a conceptual level. ModulePass is closer, except that
that would be a significant inconvenience given the way we
currently use it. ImmutablePass is also closer, except for the
requirement of notification whenever an instruction is deleted,
which ImmutablePass doesn't allow.

I believe SCEV is something that doesn't fit well in the current
Pass hierarchy. And Nick's value-range pass is in a similar
situation. Also, I've been thinking about making what's now
ValueTracking.cpp into a pass so that it can memoize results;
such a pass would be yet another instance of this. I'd be
interested in discussing ideas for this problem.

But getting back to the patch itself, I see it has a
runOnFunction that eagerly computes results for all instructions
in all loops in a function. I'd like to suggest that it compute
results on demand, similar to how SCEV works.

Dan




More information about the llvm-commits mailing list