[Bug tree-optimization/114322] [14 Regression] SCEV analysis failed for bases like A[(i+x)*stride] since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322 --- Comment #4 from GCC Commits --- The master branch has been updated by Hao Liu : https://gcc.gnu.org/g:4c276896d646c2dbc8047fd81d6e65f8c5ecf01d commit r14-9569-g4c276896d646c2dbc8047fd81d6e65f8c5ecf01d Author: Hao Liu Date: Wed Mar 20 17:37:01 2024 +0800 testsuite: add the case to cover the vectorization of A[(i+x)*stride] [PR114322] This issues has been fixed by r14-9540-ge0e9499a in PR114151. Tested on aarch64-linux-gnu. gcc/testsuite/ChangeLog: PR tree-optimization/114322 * gcc.dg/vect/pr114322.c: New testcase.
[Bug tree-optimization/114322] [14 Regression] SCEV analysis failed for bases like A[(i+x)*stride] since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed by reverting the offending change. Feel free to submit a testcase for the testsuite covering your case.
[Bug tree-optimization/114322] [14 Regression] SCEV analysis failed for bases like A[(i+x)*stride] since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e0e9499aeffdaca88f0f29334384aa5f710a81a4 commit r14-9540-ge0e9499aeffdaca88f0f29334384aa5f710a81a4 Author: Richard Biener Date: Tue Mar 19 12:24:08 2024 +0100 tree-optimization/114151 - revert PR114074 fix The following reverts the chrec_fold_multiply fix and only keeps handling of constant overflow which keeps the original testcase fixed. A better solution might involve ranger improvements or tracking of assumptions during SCEV analysis similar to what niter analysis does. PR tree-optimization/114151 PR tree-optimization/114269 PR tree-optimization/114322 PR tree-optimization/114074 * tree-chrec.cc (chrec_fold_multiply): Restrict the use of unsigned arithmetic when actual overflow on constant operands is observed. * gcc.dg/pr68317.c: Revert last change.
[Bug tree-optimization/114322] [14 Regression] SCEV analysis failed for bases like A[(i+x)*stride] since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug tree-optimization/114322] [14 Regression] SCEV analysis failed for bases like A[(i+x)*stride] since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Last reconfirmed||2024-03-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. The issue is we have { x_12(D), +, 1 } * stride_11(D) which doesn't behave the same with respect to overflow as { x_12(D) * stride_11(D), +, stride_11(D) } and because of that we analyze it as (int) {(unsigned) x_12(D) * (unsigned) stride_11(D), +, (unsigned) stride_11(D) } as it might wrap. But then then sign-extension to long unsigned int is no longer affine. _1 = x_12(D) + i_20; _2 = _1 * stride_11(D); _3 = (long unsigned int) _2; _4 = _3 * 2; _5 = A_13(D) + _4; _6 = *_5; The problematical case is x == N < 0 where the last - N might now overflow with the new SCEV. The correctness means that we'll now more often run into these issues for IVs smaller than pointer width. With -m32 we can analyze the DR to Creating dr for *_5 offset from base address: 0 constant offset from base address: 0 step: (ssizetype) ((unsigned int) stride_11(D) * 2) base alignment: 2 base misalignment: 0 offset alignment: 256 step alignment: 2 base_object: *A_13(D) + (sizetype) ((unsigned int) stride_11(D) * (unsigned int) x_12(D)) * 2 Access function 0: {0B, +, (unsigned int) stride_11(D) * 2}_1 If you had written sum += A[i*stride + x*stride]; it might have worked but unfortunately EVRP transforms this back to (i+x)*stride because it knows stride isn't zero. In the end this means it's our failure that we fail to handle 2 * (unsigned long)({ x_12(D), +, 1 } * stride_11(D)) as valid evolution for further analysis - of course the multiplication by two in an unsigned type might overflow as well.