Zero factor leads to division by zero and failure of corresponding
assert as shown in PR50765. We should filter out such factors.
Details
Diff Detail
Event Timeline
Ideally we should reject early when stride is zero, but in this case we won't be able to detect this early since stride zero is in a form of add expression.
(((3 + (-1 * (74 smax (1 + %tmp3)))<nsw>)<nuw><nsw> * {(-2 + (-2 * (trunc i64 undef to i32))),+,-2}<%bb1>) + ((6 + (-2 * (74 smax (1 + %tmp3))))<nuw> * {(1 + (trunc i64 undef to i32)),+,1}<%bb1>)) // Zero stride as the LHS
After getExactSDiv pull out common factor 2 , then we get an add expression that turn out to be zero.
LGTM to me as well.
llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp | ||
---|---|---|
2713 | Not a problem with this patch, but dang this code is suspicious. It appears to be wanting to check whether one factor divides another, but a) it's *asserting* the divide is exact, and b) it's discarding any remainder. That probably wasn't what was actually wanted here... |
That's a point where we could try to improve SCEV. But generally, it's not correct to assume that SCEV will or will not fully simplify something. It has a lot of limitations, one of which is depth threshold which simply cuts the simplification process for sake of saving CT.
Not a problem with this patch, but dang this code is suspicious. It appears to be wanting to check whether one factor divides another, but a) it's *asserting* the divide is exact, and b) it's discarding any remainder. That probably wasn't what was actually wanted here...