[LLVMdev] ScalarEvolution, HowManyLessThans question for step > 1

Brendon Cahoon bcahoon at codeaurora.org
Fri Nov 16 10:56:09 PST 2012



I have a question about some code in ScalarEvolution.cpp, in the function
HowManyLessThans.  Specifically, this function returns CouldNotCompute if
the iteration step is greater than one even when the NoWrap flags are set
(if the step goes past the limit and wraps).    Here's the comment:


   } else if (isKnownPositive(Step)) {

      // Test whether a positive iteration can step past the limit

      // value and past the maximum value for its type in a single step.

      // Note that it's not sufficient to check NoWrap here, because even

      // though the value after a wrap is undefined, it's not undefined

      // behavior, so if wrap does occur, the loop could either terminate or

      // loop infinitely, but in either case, the loop is guaranteed to

      // iterate at least until the iteration where the wrapping occurs.


I have no doubt that there is a good reason for this code to work this way
(there is a specific check in trip-count9.ll).  I'm just trying to
understand it better.  I'm assuming that when the previous version of this
code checked the NoWrap flag, that it caused a problem with some
optimization pass?  If so, does anyone recall the pass.


I'm also curious if the -f[no]-strict-overflow flag has any impact on the
assumptions?  Or, could the function check NoWrap for the unsigned case


The motivating example for this question occurs because we're not unrolling
loops with a run-time trip count when the loop induction variable is a
pointer and the loop end check is another pointer.  For example,


  void ex( int n, int* a, int* c ) {

   int b  = 1; int *ae = a + n;

    while ( a < ae) {

      c ++; b += *c; *a++ = b;








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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121116/5906db73/attachment.html>

More information about the llvm-dev mailing list