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.

  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: link
Be 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).