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/105175] [12 Regression] Pointless warning about missed vector optimization Date: Wed, 06 Apr 2022 09:17:45 +0000 [thread overview] Message-ID: <bug-105175-4-p2cTEXKHzJ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-105175-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105175 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmalcolm at gcc dot gnu.org, | |msebor at gcc dot gnu.org --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- @item -Wvector-operation-performance @opindex Wvector-operation-performance @opindex Wno-vector-operation-performance Warn if vector operation is not implemented via SIMD capabilities of the architecture. Mainly useful for the performance tuning. Vector operation can be implemented @code{piecewise}, which means that the scalar operation is performed on every vector element; @code{in parallel}, which means that the vector operation is implemented using scalars of wider type, which normally is more performance efficient; and @code{as a single scalar}, which means that vector fits into a scalar type. -- So the point is the vector lowering pass cannot distinguish people writing typedef int v2si __attribute__((vector_size(8))); v2si a, b; void foo() { a &= b; } and the vectorizer producing such code. So technically the diagnostic is correct but it was the vectorizer producing the operation. So a proper way would be to suppress OPT_Wvector_operation_performance for the vectorizer generated stmt. Unfortunately if (using_emulated_vectors_p) suppress_warning (new_stmt, OPT_Wvector_operation_performance); will not magically make warning_at (loc, OPT_Wvector_operation_performance, "vector operation will be expanded with a " "single scalar operation"); not warn. suppress_warning_at returns true, and supp is true as well (that parameter is not documented as far as I can see). So we need to guard all the warning_at with stmt-based warning_suppressed_p and there's no warning_at overload with a gimple * as location that would automagically do that it seems? There is one with rich_location * but AFAIK that doesn't cover gimple * or tree. I'm testing a patch that is IMHO too verbose (adjusting all warning_at in tree-vect-generic.cc).
next prev parent reply other threads:[~2022-04-06 9:17 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-06 7:00 [Bug rtl-optimization/105175] New: " krebbel at gcc dot gnu.org 2022-04-06 8:17 ` [Bug tree-optimization/105175] " rguenth at gcc dot gnu.org 2022-04-06 8:30 ` krebbel at gcc dot gnu.org 2022-04-06 8:49 ` rguenth at gcc dot gnu.org 2022-04-06 9:17 ` rguenth at gcc dot gnu.org [this message] 2022-04-08 6:34 ` cvs-commit at gcc dot gnu.org 2022-04-08 6:35 ` 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-105175-4-p2cTEXKHzJ@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).