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/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement Date: Thu, 21 Dec 2023 07:31:22 +0000 [thread overview] Message-ID: <bug-113091-4-7Il81sOMjo@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-113091-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113091 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Last reconfirmed| |2023-12-21 Status|UNCONFIRMED |NEW --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- "The use stmt is "_2 = (int) _1", whose pattern statement is "patt_64 = (int) patt_63", which is not referenced by any original or other pattern statements. Or in other word, the orig_stmt could be absorbed into a vector operation, without any outlier scalar use." That means the code sees that _2 = (int) _1 isn't vectorized (the pattern stmt isn't actually used) which means _2 = (int) _1 stays in the code and thus _1 is live. The issue here is that because the "outer" pattern consumes patt_64 = (int) patt_63 it should have adjusted _2 = (int) _1 stmt-to-vectorize as being the outer pattern root stmt for all this logic to work correctly. Otherwise we have no means of identifying whether a scalar stmt takes part in vectorization or not. I'm not sure what restrictions we place on pattern recognition of patterns - do we require single-uses or do we allow the situation that one vectorization path picks up the "inner" pattern while another picks the "outer" one? In theory we can hack up the liveness analysis but as you noticed that isn't the part doing the costing. The costing part is just written in the very same way (vect_bb_vectorization_profitable_p, specifically vect_slp_gather_vectorized_scalar_stmts and vect_bb_slp_scalar_cost). Basically the scalar cost is the cost of the scalar stmts that are fully replaced (can be DCEd after vectorization) by the vector stmts.
next prev parent reply other threads:[~2023-12-21 7:31 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-12-20 9:54 [Bug tree-optimization/113091] New: " fxue at os dot amperecomputing.com 2023-12-20 13:09 ` [Bug tree-optimization/113091] " rguenth at gcc dot gnu.org 2023-12-21 5:25 ` fxue at os dot amperecomputing.com 2023-12-21 5:27 ` fxue at os dot amperecomputing.com 2023-12-21 7:31 ` rguenth at gcc dot gnu.org [this message] 2023-12-21 11:01 ` rsandifo at gcc dot gnu.org 2023-12-22 3:55 ` fxue at os dot amperecomputing.com 2023-12-26 15:16 ` fxue at os dot amperecomputing.com 2023-12-29 10:35 ` fxue at os dot amperecomputing.com 2024-01-16 3:36 ` cvs-commit at gcc dot gnu.org 2024-01-31 3:13 ` fxue at os dot amperecomputing.com
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-113091-4-7Il81sOMjo@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).