[llvm-commits] [llvm] r75252 - in /llvm/trunk: include/llvm/Analysis/ScalarEvolution.h include/llvm/Analysis/ScalarEvolutionExpressions.h lib/Analysis/ScalarEvolution.cpp test/Transforms/IndVarSimplify/iv-sext.ll

[Dan Gohman]

On Jul 10, 2009, at 10:05 AM, Nick Lewycky wrote:


> 2009/7/10 Dan Gohman <gohman at apple.com>
> Author: djg
> Date: Fri Jul 10 11:42:52 2009
> New Revision: 75252
>
> URL: http://llvm.org/viewvc/llvm-project?rev=75252&view=rev
> Log:
> Generalize ScalarEvolution's cast-folding code to support more kinds
> of loops. Add several new functions to for working with  
> ScalarEvolution's
> add-hoc value-range analysis functionality.
>
> Dan, this looks great! Does this kill off LoopVR?

Almost :-). I think the only things left to do are porting LoopVR's
SCEVUDivExpr and SCEVMulExpr logic to ConstantRange's udiv and multiply.
Interested in helping? :-)

>
> Why does isKnownPositive(Step) control whether the range should be  
> considered signed or unsigned? You're already considering it  
> 'signed' just by asking the question; an unsigned value is always  
> positive :-)

I'm not sure what you're asking. Thee three places in the code where
isKnownPositive(Step) is used, the signedness interpretation of the
range is already determined.

>
> The intuition here is that getSignedRange and getUnsignedRange could  
> be merged by checking for the SLT, SGT and ULE cases all in one  
> implementation which in turn leads to collapsing of cases in a lot  
> of code. (Oh, and the SCEVUnknown code could do both types of  
> computation and just take the smaller of the two resulting ranges.)

Yeah, getSignedRange and getUnsignedRange are fairly similar and
probably could be merged, with care. There's lots of room for
improvement in their SCEVAddRecExpr analyses too :-).

Dan