[llvm-testresults] buildbot failure in lab.llvm.org on phase1 - sanity

[llvmlab-buildmaster at lab.llvm.org]

The Buildbot has detected a new failure on builder phase1 - sanity while building llvm.
Full details are available at:
 http://lab.llvm.org:8013/builders/phase1%20-%20sanity/builds/13024

Buildbot URL: http://lab.llvm.org:8013/

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 193015
Blamelist: atrick

BUILD FAILED: failed

sincerely,
 -The Buildbot


================================================================================

CHANGES:
Files:
 lib/Analysis/ScalarEvolution.cpp
 test/Analysis/ScalarEvolution/trip-count9.ll
On: http://10.1.1.2/svn/llvm-project
For: llvm
At: Fri 18 Oct 2013 16:50:30
Changed By: atrick
Comments: SCEV should use NSW to get trip count for positive nonunit stride loops.

SCEV currently fails to compute loop counts for nonunit stride
loops. This comes up frequently. It prevents loop optimization and
forces vectorization to insert extra loop checks.

For example:
void foo(int n, int *x) {
 for (int i = 0; i < n; i += 3) {
   x[i] = i;
   x[i+1] = i+1;
   x[i+2] = i+2;
 }
}

We need to properly handle the case in which limit > INT_MAX-stride. In
the above case: n > INT_MAX-3. In this case the loop counter will step
beyond the limit and overflow at the same time. However, knowing that
signed integer overlow in undefined, we can assume the loop test
behavior is arbitrary after overflow. This obeys both C undefined
behavior rules, and the more strict LLVM poison value rules.

I'm finally fixing this in response to Hal Finkel's persistence.
The most probable reason that we never optimized this before is that
we were being careful to handle case where the developer expected a
side-effect free infinite loop relying on overflow:

for (int i = 0; i < n; i += s) {
  ++j;
}
return j;

If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might
expect an infinite loop. However there are plenty of ways to achieve
this effect without relying on undefined behavior of signed overflow.Properties: 




LOGS: