public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/105591] [13 Regression] ICE: in tree_to_poly_uint64, at tree.cc:3250 with -O -mavx512f -mno-avx2 since r13-379 Date: Fri, 13 May 2022 12:43:49 +0000 [thread overview] Message-ID: <bug-105591-4-0uXrKsO2SG@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-105591-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105591 --- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Because VEC_PERM_EXPR doesn't require the mask argument to be constant (and neither does __builtin_shuffle, unlike e.g. __builtin_shufflevector). If the mask argument remains non-constant until end of compilation, the modulo N or 2*N needs to be done at runtime (of course unless used hw instruction performs something like that itself). And that is the reason why it is defined this way. During compilation there are way too many spots where a constant could be propagated into a formerly non-constant operand of the VEC_PERM_EXPR, and no guarantee that all such propagations (it isn't in a single spot in a single pass, it is really many) will do some extra code to canonicalize it. It can be, but we can't guarantee it. For __builtin_shufflevector, we supposedly want to introduce some VEC_PERM_EXPR variant which would only allow constant mask argument and which would have different behavior, -1 standing for I don't care rather than -1 % N or -1 % (2*N). If we introduce something like that, we could certainly require that the new expr's operand is only -1..N-1 or -1..2*N-1 and could have then say match.pd that turns a VEC_PERM_EXPR with a constant argument into the new expr with canonical argument.
next prev parent reply other threads:[~2022-05-13 12:43 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-13 11:09 [Bug tree-optimization/105591] New: [13 Regression] ICE: in tree_to_poly_uint64, at tree.cc:3250 with -O -mavx512f -mno-avx2 zsojka at seznam dot cz 2022-05-13 11:40 ` [Bug tree-optimization/105591] " rguenth at gcc dot gnu.org 2022-05-13 11:41 ` crazylht at gmail dot com 2022-05-13 11:43 ` jakub at gcc dot gnu.org 2022-05-13 11:48 ` [Bug tree-optimization/105591] [13 Regression] ICE: in tree_to_poly_uint64, at tree.cc:3250 with -O -mavx512f -mno-avx2 since r13-379 zsojka at seznam dot cz 2022-05-13 11:50 ` jakub at gcc dot gnu.org 2022-05-13 11:54 ` crazylht at gmail dot com 2022-05-13 11:58 ` jakub at gcc dot gnu.org 2022-05-13 11:59 ` jakub at gcc dot gnu.org 2022-05-13 12:10 ` jakub at gcc dot gnu.org 2022-05-13 12:34 ` crazylht at gmail dot com 2022-05-13 12:43 ` jakub at gcc dot gnu.org [this message] 2022-05-13 12:45 ` crazylht at gmail dot com 2022-05-17 0:59 ` cvs-commit at gcc dot gnu.org 2022-05-17 1:01 ` crazylht at gmail dot com 2022-10-19 10:10 ` 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-105591-4-0uXrKsO2SG@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).