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/114027] [11/12/13/14 Regression] miscompile at `-O3 -fno-vect-cost-model -msse4.2` Date: Thu, 22 Feb 2024 09:37:15 +0000 [thread overview] Message-ID: <bug-114027-4-owEhPZxreT@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114027-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 --- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- We're detecting a COND_REDUCTION with a chain. It seems to work (and vectorize) with -march=znver4 using AVX sized vectors (but AVX512 style masking). I think what goes wrong is treating the COND_REDUCTION as MAX reduction by only checking the last COND which looks like c_lsm.9_18 = _76 ? prephitmp_26 : 0; but the previous one is prephitmp_26 = _69 ? c_lsm.9_30 : -3; I'm not too familiar with the condition reduction code, the reduction is classified as cond_reduc_dt == vect_constant_def and so we run into else if (cond_reduc_dt == vect_constant_def) { enum vect_def_type cond_initial_dt; tree cond_initial_val = vect_phi_initial_value (reduc_def_phi); vect_is_simple_use (cond_initial_val, loop_vinfo, &cond_initial_dt); if (cond_initial_dt == vect_constant_def && types_compatible_p (TREE_TYPE (cond_initial_val), TREE_TYPE (cond_reduc_val))) { tree e = fold_binary (LE_EXPR, boolean_type_node, cond_initial_val, cond_reduc_val); if (e && (integer_onep (e) || integer_zerop (e))) { if (dump_enabled_p ()) dump_printf_loc (MSG_NOTE, vect_location, "condition expression based on " "compile time constant.\n"); /* Record reduction code at analysis stage. */ STMT_VINFO_REDUC_CODE (reduc_info) = integer_onep (e) ? MAX_EXPR : MIN_EXPR; STMT_VINFO_REDUC_TYPE (reduc_info) = CONST_COND_REDUCTION; } and the loop classifying and computing cond_reduc_val just looks at the first chain element ... This should possibly be merged with the loop going over all chain stmts but a more conservative fix for the latent(?) issue might be the following (but that also cuts out conversions in the chain): diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc index 5a5865c42fc..e19896eef79 100644 --- a/gcc/tree-vect-loop.cc +++ b/gcc/tree-vect-loop.cc @@ -7762,14 +7762,16 @@ vectorizable_reduction (loop_vec_info loop_vinfo, if (op.code == COND_EXPR) { /* Record how the non-reduction-def value of COND_EXPR is defined. */ - if (dt == vect_constant_def) + if (reduc_chain_length != 1) + ; + else if (dt == vect_constant_def) { cond_reduc_dt = dt; cond_reduc_val = op.ops[i]; } - if (dt == vect_induction_def - && def_stmt_info - && is_nonwrapping_integer_induction (def_stmt_info, loop)) + else if (dt == vect_induction_def + && def_stmt_info + && is_nonwrapping_integer_induction (def_stmt_info, loop)) { cond_reduc_dt = dt; cond_stmt_vinfo = def_stmt_info; I think it's latent even before the bisected rev.
next prev parent reply other threads:[~2024-02-22 9:37 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-21 2:06 [Bug target/114027] New: [14] RISC-V vector: miscompile at -O3 patrick at rivosinc dot com 2024-02-21 2:16 ` [Bug target/114027] " sjames at gcc dot gnu.org 2024-02-21 2:39 ` pinskia at gcc dot gnu.org 2024-02-22 6:39 ` pan2.li at intel dot com 2024-02-22 7:43 ` pan2.li at intel dot com 2024-02-22 8:57 ` rdapp at gcc dot gnu.org 2024-02-22 8:59 ` sjames at gcc dot gnu.org 2024-02-22 9:05 ` pinskia at gcc dot gnu.org 2024-02-22 9:06 ` rdapp at gcc dot gnu.org 2024-02-22 9:13 ` [Bug tree-optimization/114027] [14 Regression] " pinskia at gcc dot gnu.org 2024-02-22 9:20 ` [Bug tree-optimization/114027] [11/12/13/14 Regression] miscompile at `-O3 -fno-vect-cost-model -msse4.2` pinskia at gcc dot gnu.org 2024-02-22 9:26 ` jakub at gcc dot gnu.org 2024-02-22 9:37 ` rguenth at gcc dot gnu.org [this message] 2024-02-22 9:37 ` rguenth at gcc dot gnu.org 2024-02-22 9:37 ` rguenth at gcc dot gnu.org 2024-02-22 9:48 ` rguenth at gcc dot gnu.org 2024-02-22 12:14 ` cvs-commit at gcc dot gnu.org 2024-03-21 11:49 ` [Bug tree-optimization/114027] [11/12/13 " cvs-commit at gcc dot gnu.org 2024-03-26 7:39 ` [Bug tree-optimization/114027] [11/12 " chenglulu at loongson dot cn 2024-03-26 8:48 ` cvs-commit at gcc dot gnu.org 2024-03-26 8:48 ` cvs-commit at gcc dot gnu.org 2024-03-26 8:49 ` rguenth at gcc dot gnu.org 2024-05-16 9:56 ` cvs-commit at gcc dot gnu.org 2024-05-16 9:56 ` cvs-commit at gcc dot gnu.org 2024-06-21 9:22 ` [Bug tree-optimization/114027] [11 " cvs-commit at gcc dot gnu.org 2024-06-21 9:22 ` cvs-commit at gcc dot gnu.org 2024-06-21 9:36 ` 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-114027-4-owEhPZxreT@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).