[llvm-dev] Working on FP SCEV Analysis

[Andrew Trick via llvm-dev]

> On May 18, 2016, at 6:25 AM, Demikhovsky, Elena via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> > Even then, I'd personally want to see further evidence of why the correct solution is to model the floating point IV in SCEV rather than find a more powerful way of converting the IV to an integer that models > the non-integer values taken on by the IV. As an example, if the use case is the following code with appropriate flags to relax IEEE semantics so this looks like normal algabra etc:
>  
> >   for (float f = 0.01f; f < 1.0f; f += 0.01f)  ç *A*
>     ...
>  
> > I'd rather see us cleverly turn it into:
>  
> >   float f = 0.01f;
> >   for (int i = 1; i < 100; i += 1, f += 0.01f) ç *B*
>  
> I can later try to enhance IndVarSimplify::handleFloatingPointIV() in order to convert *A* to *B*.
> But *B* is exactly the case I’m starting from. The main IV “i” is integer. The variable “f” is also considered as IV in this loop.
> And this loop is not vectorized because “f” is floating point.
> I don’t think that the case *B* is uncommon.
>  

I’m not sure what terminology to use (help), but we should make a fundamental distinction between these cases (copying from Hideki):

void foo(TTT *a, int N, TTT x, TTT y){
    int i;
    for (i=0;i<N;i++){
        x+=y;
    }
}

…where we have a pure reduction.

void foo(TTT *a, int N, TTT x, TTT y){
    int i;
    for (i=0;i<N;i++){
        A[i] = x;
        x+=y;
    }
}

…where we have a FP induction variable (such that all intermediate values need to be computed).

I pretty much agree with everything Danny, Sanjoy, and Hideki said.

-Andy