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 target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394 Date: Thu, 22 Oct 2020 07:19:36 +0000 [thread overview] Message-ID: <bug-97521-4-RcO7FaeyNz@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-97521-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > And we do that because: > case VECTOR_CST: > { > tree tmp = NULL_TREE; > if (VECTOR_MODE_P (mode)) > return const_vector_from_tree (exp); > scalar_int_mode int_mode; > if (is_int_mode (mode, &int_mode)) > { > if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp))) > return const_scalar_mask_from_tree (int_mode, exp); I think const_scalar_mask_from_tree is completely wrong in ignoring the precision of the VECTOR_BOOLEAN component type. At least it is inconsistent with the processing of VECTOR_BOOLEAN_TYPE_P CTORs. Now I can see that this was intended for AVX512 but I can't see how this "inconsistency" can possibly work if you consider the use of _1: _19 = BIT_FIELD_REF <_1, 64, 0>; if you disable TER then how should we ever able to "reinterpret" the BIT_FIELD_REF to the "narrowed" view of the VECTOR_BOOLEAN_TYPE_P mask? A heuristic for an intermediate hack might be to skip const_scalar_mask_from_tree when the component precision times the number of elements equals the mode precision of the vector. Thus the following fixes the testcase diff --git a/gcc/expr.c b/gcc/expr.c index 9d951e82522..d87bda777d0 100644 --- a/gcc/expr.c +++ b/gcc/expr.c @@ -10356,7 +10356,10 @@ expand_expr_real_1 (tree exp, rtx target, machine_mode tmode, scalar_int_mode int_mode; if (is_int_mode (mode, &int_mode)) { - if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp))) + if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp)) + && maybe_ne (TYPE_PRECISION (TREE_TYPE (TREE_TYPE (exp))) + * TYPE_VECTOR_SUBPARTS (TREE_TYPE (exp)), + GET_MODE_PRECISION (int_mode))) return const_scalar_mask_from_tree (int_mode, exp); else but I have no easy access to a AVX512 runtime system (and no idea how to make dejagnu use sde for a i386.exp testsuite run). On a AVX2 system i386.exp is clean with the above. Thoughts? [AVX512 should have used VnBImode like SVE does] > where the VECTOR_CST type is now a vector boolean with DImode element type > and TImode as the (poor man's) vector mode. > > So, the question is how to differentiate between vector booleans that want > to be a bitmask in an integral mode vs. poor man's vector booleans for which > we'd want to fallthru into the VIEW_CONVERT_EXPR code below this. > And what other spots need that. > Perhaps check if the bitsize (or precision?) of the vector type's mode is > equal to bitsize (or precision?) of the element mode times number of > elements in the vector?
next prev parent reply other threads:[~2020-10-22 7:19 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-21 16:27 [Bug target/97521] New: [11 Regression] wrong code with -mno-sse2 zsojka at seznam dot cz 2020-10-21 16:37 ` [Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394 jakub at gcc dot gnu.org 2020-10-21 16:56 ` jakub at gcc dot gnu.org 2020-10-21 17:07 ` jakub at gcc dot gnu.org 2020-10-21 18:33 ` marxin at gcc dot gnu.org 2020-10-22 7:19 ` rguenth at gcc dot gnu.org [this message] 2020-10-22 7:25 ` jakub at gcc dot gnu.org 2020-10-22 8:32 ` crazylht at gmail dot com 2020-10-22 8:45 ` rguenther at suse dot de 2020-10-22 8:52 ` jakub at gcc dot gnu.org 2020-10-22 8:58 ` jakub at gcc dot gnu.org 2020-10-22 9:00 ` crazylht at gmail dot com 2020-10-22 9:01 ` jakub at gcc dot gnu.org 2020-10-22 9:50 ` rguenther at suse dot de 2020-10-22 10:59 ` cvs-commit at gcc dot gnu.org 2020-10-22 11:11 ` rguenth at gcc dot gnu.org 2020-10-23 6:04 ` rguenth at gcc dot gnu.org 2020-10-23 6:21 ` rguenth at gcc dot gnu.org 2020-10-23 6:23 ` cvs-commit at gcc dot gnu.org 2020-10-23 6:58 ` rguenth at gcc dot gnu.org 2020-10-23 7:00 ` rguenth at gcc dot gnu.org 2020-10-23 7:06 ` rguenth at gcc dot gnu.org 2020-10-23 8:28 ` ams at gcc dot gnu.org 2020-10-23 8:47 ` ams at gcc dot gnu.org 2020-10-26 11:28 ` cvs-commit at gcc dot gnu.org 2020-10-26 11:28 ` 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-97521-4-RcO7FaeyNz@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).