public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ktkachov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/109636] [14 Regression] ICE: in paradoxical_subreg_p, at rtl.h:3205 with -O -mcpu=a64fx
Date: Fri, 28 Apr 2023 14:41:56 +0000	[thread overview]
Message-ID: <bug-109636-4-wH6unCQ9WE@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-109636-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636

--- Comment #7 from ktkachov at gcc dot gnu.org ---
(In reply to rsandifo@gcc.gnu.org from comment #6)
> Ugh.  I guess we've got no option but to force the original
> subreg into a fresh register, but that's going to pessimise
> cases where arithmetic is done on tuple types.
> 
> Perhaps we should just expose the SVE operation as a native
> V2DI one.  Handling predicated ops would be a bit more challenging
> though.

I did try a copy_to_mode_reg to a fresh V2DI register for non-REG_P arguments
and that did progress, but (surprisingly?) still ICEd during fwprop:
during RTL pass: fwprop1
mulice.c: In function 'foom':
mulice.c:17:1: internal compiler error: in paradoxical_subreg_p, at rtl.h:3205
   17 | }
      | ^
0xe903b9 paradoxical_subreg_p(machine_mode, machine_mode)
        $SRC/gcc/rtl.h:3205
0xe903b9 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<2u, unsigned long>)
        $SRC/gcc/simplify-rtx.cc:7533
0xe1b5f7 insn_propagation::apply_to_rvalue_1(rtx_def**)
        $SRC/gcc/recog.cc:1176
0xe1b3d8 insn_propagation::apply_to_rvalue_1(rtx_def**)
        $SRC/gcc/recog.cc:1118
0xe1b7b7 insn_propagation::apply_to_rvalue_1(rtx_def**)
        $SRC/gcc/recog.cc:1254
0xe1babf insn_propagation::apply_to_pattern_1(rtx_def**)
        $SRC/gcc/recog.cc:1361
0xe1bae4 insn_propagation::apply_to_pattern(rtx_def**)
        $SRC/gcc/recog.cc:1383
0x1c22e5b try_fwprop_subst_pattern
        $SRC/gcc/fwprop.cc:454
0x1c22e5b try_fwprop_subst
        $SRC/gcc/fwprop.cc:627
0x1c239a9 forward_propagate_and_simplify
        $SRC/gcc/fwprop.cc:823
0x1c239a9 forward_propagate_into
        $SRC/gcc/fwprop.cc:886
0x1c23bc1 fwprop_insn
        $SRC/gcc/fwprop.cc:943
0x1c23d98 fwprop
        $SRC/gcc/fwprop.cc:995
0x1c240e1 execute
        $SRC/gcc/fwprop.cc:1033
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

fwprop ended up creating:
(mult:VNx2DI (subreg:VNx2DI (reg/v:V2DI 95 [ v ]) 0)
    (subreg:VNx2DI (subreg:V2DI (reg/v:OI 97 [ w ]) 16) 0))

and something blew up anyway, so it seems the RTL passes *really* don't like
these kind of subregs ;)
I'll look into expressing these ops as native V2DI patterns. I guess for the
unpredicated SVE2 mul that's easy, but for the predicated forms perhaps we can
have them consume a predicate register, generated at expand time, similar to
the  aarch64-sve.md expanders. Not super-pretty but maybe it'll be enough

  parent reply	other threads:[~2023-04-28 14:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-26 17:28 [Bug target/109636] New: " zsojka at seznam dot cz
2023-04-26 19:08 ` [Bug target/109636] " pinskia at gcc dot gnu.org
2023-04-26 22:26 ` ktkachov at gcc dot gnu.org
2023-04-26 22:42 ` pinskia at gcc dot gnu.org
2023-04-27  8:26 ` ktkachov at gcc dot gnu.org
2023-04-28  8:17 ` ktkachov at gcc dot gnu.org
2023-04-28  8:25 ` rsandifo at gcc dot gnu.org
2023-04-28 14:41 ` ktkachov at gcc dot gnu.org [this message]
2024-01-10  8:01 ` [Bug target/109636] [14 Regression] ICE: in paradoxical_subreg_p, at rtl.h:3205 with -O -march=armv8.4-a+sve pinskia at gcc dot gnu.org
2024-01-10  8:03 ` pinskia at gcc dot gnu.org
2024-01-10  8:05 ` pinskia at gcc dot gnu.org
2024-01-12 17:55 ` tnfchris at gcc dot gnu.org
2024-01-24 15:58 ` cvs-commit at gcc dot gnu.org
2024-01-24 16:01 ` tnfchris 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-109636-4-wH6unCQ9WE@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).