https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636
--- Comment #7 from ktkachov at gcc dot gnu.org ---
(In reply to rsand...@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
