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/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3 Date: Tue, 18 Apr 2023 09:49:21 +0000 [thread overview] Message-ID: <bug-109539-4-GWKRt4old7@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-109539-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- So what we try to do is, when check_pointer_uses follows the use chain of 'ptr' through say ptr2 = ptr + 4; then it wants to visit ptr2 uses as well. For PHIs we get to ptr2 = PHI <..., ptr, ...>; and we want to consider uses of ptr2 only if all other PHI arguments are "related" to 'ptr'. To prove that we perform complicated gymnastics, in particular the only real check done is if (!ptr_derefs_may_alias_p (p, q)) return false; and that's of course incredibly weak. To disprove relatedness the pointers_related_p recurses, but only when either of both pointers are defined by a PHI. It uses pointer-query to skip chains of pointer adjustments up to such definition. So we basically do forward relatedness in check_pointer_uses and then backward relatedness in pointers_related_p. I think we should eschew that completely and only try to handle "forward" PHIs by the iteration in check_pointer_uses itself.
next prev parent reply other threads:[~2023-04-18 9:49 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-18 6:48 [Bug tree-optimization/109539] New: " marxin at gcc dot gnu.org 2023-04-18 6:50 ` [Bug tree-optimization/109539] " marxin at gcc dot gnu.org 2023-04-18 8:22 ` marxin at gcc dot gnu.org 2023-04-18 8:44 ` rguenth at gcc dot gnu.org 2023-04-18 9:12 ` rguenth at gcc dot gnu.org 2023-04-18 9:49 ` rguenth at gcc dot gnu.org [this message] 2023-04-18 12:38 ` cvs-commit at gcc dot gnu.org 2023-04-18 12:38 ` cvs-commit at gcc dot gnu.org 2023-04-18 12:39 ` rguenth 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-109539-4-GWKRt4old7@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).