collectUpperBound hits an assertion when the back edge count is wider then the desired type.
If that happens, truncate the backedge count.
Differential D9455
[DependenceAnalysis] Fix for PR21585: collectUpperBound triggers asserts philip.pfaffe on May 2 2015, 6:08 AM. Authored by
Details
Diff Detail Event Timeline
Comment Actions LGTM. Btw, here's another test case that exposes the bug, and is fixed by this patch. ; RUN: opt < %s -analyze -basicaa -da > /dev/null ; Test for a bug, which caused an assert in ScalarEvolution because ; the Dependence Analyzer attempted to zero extend a type to a smaller ; type. ; void t(unsigned int *a, unsigned int n) { ; for (unsigned int i = 0; i != n; i++) { ; a[(unsigned short)i] = g; ; }} @g = common global i32 0, align 4 define void @t(i32* %a, i32 %n) nounwind { entry: %cmp1 = icmp eq i32 %n, 0 br i1 %cmp1, label %for.end, label %for.body for.body: %i.02 = phi i32 [ %inc, %for.body ], [ 0, %entry ] %0 = load i32, i32* @g, align 4 %idxprom = and i32 %i.02, 65535 %arrayidx = getelementptr inbounds i32, i32* %a, i32 %idxprom store i32 %0, i32* %arrayidx, align 4 %inc = add i32 %i.02, 1 %cmp = icmp eq i32 %inc, %n br i1 %cmp, label %for.end, label %for.body for.end: ret void } Comment Actions I agree with hfinkel. Blindly truncating the upper bound leads to wrong dependence results if the subscripts wrap (due to a trip count that is larger than the subscript's type). I updated the patch to catch this early and treat the wrapping subscripts accordingly, namely by recognizing them as NonLinear. Moreover, I added Brendon's code snippet to the test, as well as two more testcases that produce wrong dependence info when wrapping subscripts are treated as Linear. I'm open for discussion on whether truncating the upper bound is the most beautiful thing to do here (as apposed to, e.g., zero extending where ever this function is used), or whether it may still lead to wrong results in any other way. |
Don't need {} here.