Bug 16358: simplify SCEVs with assumptions

[Sebastian Pop]

Hi,

I have started looking at SCEV simplify in the context of determining the number
of iterations for this loop:

void foo(int n, int *A) {
  for (short i = 0; i < n; i++)
    A[i] = 0;
}

where the niter computation is confused and answers "could not compute" because
the SCEV representation of %i contains a zext expression.

Now supposing that we remove the zext in "Expr = zext(Op i16 to i32)" by
replacing the zext with a cast(Op, i32) and this under the assumption that Expr
has values in range:
  ConstantRange Range = SE.getUnsignedRange(Expr);

With this simplified representation of %i, niter ends up with a number of
iterations of the form "%n". This assumption will then impact the computation of
other SCEVs, like the value of %i at the end of the loop, etc., and with
ScalarEvolution's caching, the same assumptions will be used in other niter or
scev analysis queries, making it almost impossible to say which SE results have
used the assumptions and which are independent.

For this reason I was thinking that the set of assumptions should be part of the
state of the ScalarEvolution, and thus users of the SCEV should either version
the transformed code with the assumptions, or otherwise if versioning is not
possible, clear out the caches of ScalarEvolution and restart the analysis under
no assumptions.

Sebastian

Arnold Schwaighofer wrote:
> 
> On Oct 11, 2013, at 4:17 PM, Sebastian Pop <spop at codeaurora.org> wrote:
> 
> > Arnold Schwaighofer wrote:
> > 
> >> Interesting, in such a framework - if I understand you correctly - whenever we
> >> simplify an expression we would have to try several assumptions: a harder
> > 
> > I think SCEV folding could compute the assumptions needed to simplify the
> > expression. Let's take the example from the bug report:
> > http://llvm.org/bugs/show_bug.cgi?id=16358
> > 
> >> 8 * (zext i32 ({0,+,2}%<for_body>) to i64)+ %C_aligned
> >> 8 * (zext i32 ({1,+,2}%<for_body>) to i64)+ %C_aligned
> >> Without knowing that for the loop <for_body> the functions "{0,+,2}%<for_body>"
> >> and "{1,+2}%<for_body>" don?t wrap, SCEV cannot remove the zext.
> > 
> > simplify would recursively reconstruct the SCEV, so it would first dive in the
> > innermost expression, and the first assumption it would extract is from
> > simplifying (zext i32 ({0,+,2}%<for_body>) to i64)
> > 
> > simplify(zext i32 ({0,+,2}%<for_body>) to i64) = {0,+,2}%<for_body> assuming
> > {0,+,2}%<for_body> does not wrap, i.e., 2*N < 2**32
> > 
> > simplify would produce two constraints:
> > 
> > 2*N < 2**32
> > 2*N+1 < 2**32
> > 
> > we should keep the one satisfying both simplified expressions:
> > 2*N+1 < 2**32
> 
> 
> Okay, I see now. I was looking at the problem top down - hence a tree of
> decisions :) - and was worried that for some examples we would have to guess a
> value. But bottom up we should have already seen such values. Right.


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation