As reported in https://bugs.freebsd.org/225345, building the FreeBSD games/scummvm port for AArch64 with clang 6.0.0 results in an assertion: Assertion failed: (ExitCount != SE.getCouldNotCompute() && "Invalid loop count"), function generateOverflowCheck, file /usr/local/poudriere/jails/head-arm64/usr/src/contrib/llvm/lib/Analysis/ScalarEvolutionExpander.cpp, line 2152. This assertion still occurs with trunk r322755, and bisection shows it has regressed with https://reviews.llvm.org/rL313012 ("[LAA] Allow more run-time alias checks by coercing pointer expressions to AddRecExprs") by Silviu Baranga. Minimized test case: // clang -cc1 -triple aarch64-- -S -O1 -vectorize-loops graphics-minimized.cpp struct { void *a(); } b; char c[6]; void d() { unsigned char *e = (unsigned char *)b.a(); unsigned short f; for (;;) { for (unsigned g; g < 4; g++) e[g] = c[g + f]; f += 4; } } Note that -vectorize-loops is essential for reproducing the assertion.
This uncovers an issue introduced in r308299. createAddRecFromPHIWithCasts shouldn't create predicates for the loop that isn't currently processed by the SCEV rewriter because we don't have a guarantee that we have the backedge taken count. @Dorit: could you have a look please?
The patch should fix the issue: https://reviews.llvm.org/D42604
(In reply to Evgeny Stupachenko from comment #2) > The patch should fix the issue: https://reviews.llvm.org/D42604 Evgeny, it looks like the patch is stuck?
(In reply to Hans Wennborg from comment #3) > (In reply to Evgeny Stupachenko from comment #2) > > The patch should fix the issue: https://reviews.llvm.org/D42604 > > Evgeny, it looks like the patch is stuck? Evgeny, Silviu: it looks like the patch is ready to be committed? This needs to land soon to be able to go into the release.
Yes, I think the patch should be ready to commit, but Evgeny seems unresponsive at the moment.
Ok, I'll turn off versioning for this case so that we can get the fix in time.
I've disabled the buggy feature in r325687 until we can get Evgeny's fix in.
(In reply to Silviu Baranga from comment #7) > I've disabled the buggy feature in r325687 until we can get Evgeny's fix in. Should we merge that, or what's the story for 6.0.0?
Yes, let's merge r325687 for 6.0.0.
(In reply to Silviu Baranga from comment #9) > Yes, let's merge r325687 for 6.0.0. Merged in r325773. Thanks!
(In reply to Silviu Baranga from comment #7) > I've disabled the buggy feature in r325687 until we can get Evgeny's fix in. @Silviu, Evgeny is out of the office this week. He should be returning on Feb-26. I'll ask him to commit his fix when he returns. Thanks, -Eric
Sure, no problem. r325687 should also be reverted once the fix goes in. -Silviu (In reply to Eric Garcia from comment #11) > (In reply to Silviu Baranga from comment #7) > > I've disabled the buggy feature in r325687 until we can get Evgeny's fix in. > > > @Silviu, > > Evgeny is out of the office this week. He should be returning on Feb-26. > I'll ask him to commit his fix when he returns. > > Thanks, > -Eric
Committed to trunk revision 326154.