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

[Nick Lewycky]

Devang Patel wrote:
> On Jun 1, 2008, at 8:54 PM, Nick Lewycky wrote:
> 
>> I've implemented an analysis pass that uses SCEV to determine value  
>> ranges of integer-typed registers.
>>
>> Currently it maintains a map of Value* to ConstantRange*, which is  
>> rather inelegant. I was thinking we could have one analysis which  
>> would do that and others that would update the central analysis.
>>
>> I also implemented an optz'n pass based on it, but it hardly  
>> optimized anything and as such is not included in this patch.
>>
>> Please comment!
> 
> 
> +static RegisterPass<LoopVR> X("loopvr", "Loop Value Ranges");
> 
> You want to register this as an analysis pass and cfe-only pass.

Fixed. Thanks.

> +static SCEVHandle getTruncateOrZeroExtend(const SCEVHandle &V, const  
> Type *Ty,
> +                                          ScalarEvolution &SE) {
> 
> Why not move this into ScalarEvolution.h ?

Done.

> +      APInt Spread_X = X.getSetSize(), Spread_Y = Y.getSetSize();
> +      APInt NewLower = X.getLower() + Y.getLower(),
> +            NewUpper = X.getUpper() + Y.getUpper() - 1;
> 
> nit-pick. I'd prefer to write this as
> 
> 	APInt NewLower = ..;
> 	APInt NewUpper = ..;
> 	

Yep, good point. Done.

> +bool LoopVR::runOnFunction(Function &F) {
> 
> 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.

> +  for (LoopInfo::iterator I = LI.begin(), E = LI.end(); I != E; ++I) {
> +    Loop *L = *I;
> 
> ...
> 
> +        Loop *LL = LI.getLoopFor(*BI);
> +        if (LL->isLoopInvariant(II)) continue;
> 
> Do you really want to check LL->isLoopInvariant(II) instead of L- 
>  >isLoopInvariant(II) here ?

We aren't iterating across all loops with 'L', only the top-level ones. 
'LL' is the inner-most loop containing this BB.

It would probably be best if we looked at every loop that contains a 
given BB, but looking at only the outer-most loop could cause us to 
compute the wrong result. (Suppose in the outer loop, the result it 
known to go from 1 to 5, but in the inner loop we know it goes from 25 
to 1, ending between 1 and 5 once the inner loop is done. We can't 
optimize instructions in the inner loop based on the 1..5 range!)

Nick