public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114322] [14 Regression] SCEV analysis failed for bases like A[(i+x)*stride] since r14-9193-ga0b1798042d033 Date: Wed, 13 Mar 2024 10:47:59 +0000 [thread overview] Message-ID: <bug-114322-4-YJAlb4Lop5@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114322-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322 Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> --- 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.
next prev parent reply other threads:[~2024-03-13 10:47 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-13 10:19 [Bug tree-optimization/114322] New: " hliu at amperecomputing dot com 2024-03-13 10:47 ` rguenth at gcc dot gnu.org [this message] 2024-03-13 13:37 ` [Bug tree-optimization/114322] " law at gcc dot gnu.org 2024-03-19 12:12 ` cvs-commit at gcc dot gnu.org 2024-03-19 12:15 ` rguenth at gcc dot gnu.org 2024-03-20 9:39 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-114322-4-YJAlb4Lop5@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).