[PATCH] D29641: [SLP] Fix for PR31847: Assertion failed: (isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant!")

[Alexey Bataev via Phabricator via llvm-commits]

ABataev added a comment.

Here is what happens with this test:
Initially we have 2 SCEVs `(-1 * %cond)` and `(-1 *%cond14)`, they are combined into `(-1 * (%cond + %cond14))<nsw>`. All these SCEVs have LoopVariant dispositions. After vectorization scalars `%cond` and `%cond14` are replaced by `undef`. SCEVs for these `undef`s have the same addresses, just like for original instructions (they are reused), but their dispositions are cleared and recalculated to LoopInvariant. But after combining of these SCEVs we get SCEV, previously used as `(-1 * (%cond + %cond14))<nsw>` (because FoldingSetNodeID, used as key, is rebuilt with the same args - identifier (scMulExpr and 2 addresses of the SCEVs, that were LoopVariant, but now are LoopInvariant)). But we did not clear the loop disposition for this SCEV, because ScalarEvolution is unable to do this. So, for two SCEVs with LoopInvariant dispositions we're getting the resulting SCEV `(-1 * (undef + undef))<nsw>`, which has disposition LoopVariant. That's why I believe we should clear loop dispositions after each successfull attempt of vectorization.


https://reviews.llvm.org/D29641