https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> --- (In reply to Andrew Pinski from comment #2) > I think the problem is we are folding the right side of the array (with the > conversion to size_t) too early. > That is: > src1[j-1] > > Is being folded too early to have (j-1)*4 > > Fixing this up in match.pd is wrong. > > This gets us the best code without any patch to match.pd: > int foo(unsigned int *__restrict src1, int i, int k, int n) > { > int j = k + n; > int sum = src1[j]; > int jj = j-1; > sum += src1[jj]; > if (i <= k) > { > j+=2; > int ii = j-3; > sum += src1[ii]; > } > return sum + j; > } > > See how j-1 and j-3 are not folded early and that fixes the issue. It's done by parser, cut from c-common.c ---------- 3182 if (TREE_CODE (intop) == MINUS_EXPR) 3183 subcode = (subcode == PLUS_EXPR ? MINUS_EXPR : PLUS_EXPR); 3184 /* Convert both subexpression types to the type of intop, 3185 because weird cases involving pointer arithmetic 3186 can result in a sum or difference with different type args. */ 3187 ptrop = build_binary_op (EXPR_LOCATION (TREE_OPERAND (intop, 1)), 3188 subcode, ptrop, 3189 convert (int_type, TREE_OPERAND (intop, 1)), 3190 true); 3191 intop = convert (int_type, TREE_OPERAND (intop, 0)); 3192 } ---------- ptrop ---> src1 + 18446744073709551612; intop ---> j It seems on purpose???