https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116314
Bug ID: 116314
Summary: ICE after fixing PR116142 and implementing
vec_widen_smult_{odd,even}_M for LoongArch
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
After PR116142 is fixed I attempted again to add vec_widen_smult_{odd,even}_M
for LoongArch:
diff --git a/gcc/config/loongarch/simd.md b/gcc/config/loongarch/simd.md
index 00ff2823a4e..7b2d006e261 100644
--- a/gcc/config/loongarch/simd.md
+++ b/gcc/config/loongarch/simd.md
@@ -475,6 +475,26 @@ (define_insn "neg<mode>2"
[(set_attr "type" "simd_logic")
(set_attr "mode" "<MODE>")])
+(define_expand "vec_widen_smult_even_v8hi"
+ [(match_operand:V4SI 0 "register_operand" "=f")
+ (match_operand:V8HI 1 "register_operand" " f")
+ (match_operand:V8HI 2 "register_operand" " f")]
+ "ISA_HAS_LSX"
+{
+ emit_insn (gen_lsx_vmulwev_w_h (operands[0], operands[1], operands[2]));
+ DONE;
+})
+
+(define_expand "vec_widen_smult_odd_v8hi"
+ [(match_operand:V4SI 0 "register_operand" "=f")
+ (match_operand:V8HI 1 "register_operand" " f")
+ (match_operand:V8HI 2 "register_operand" " f")]
+ "ISA_HAS_LSX"
+{
+ emit_insn (gen_lsx_vmulwod_w_h (operands[0], operands[1], operands[2]));
+ DONE;
+})
+
; The LoongArch SX Instructions.
(include "lsx.md")
It works for the test case in PR116142. But for a test case where the input
vector cannot be hold in one register:
short x[16], y[16];
int test() {
int ret = 0;
for (int i = 0; i < 16; i++)
ret += x[i] * y[i];
return ret;
}
$ ./gcc/cc1 t.c -nostdinc -O2 -fdump-tree-vect-details -o-
t.c: In function ‘test’:
t.c:3:5: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.cc:13396
3 | int test() {
| ^~~~
0x296cde4 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:491
0x29498c0 fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1772
0x1a1911f vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
../../gcc/gcc/tree-vect-stmts.cc:13396
0x1a8f9e1 vect_schedule_slp_node
../../gcc/gcc/tree-vect-slp.cc:9970
0x1a909c9 vect_schedule_scc
../../gcc/gcc/tree-vect-slp.cc:10208
0x1a90860 vect_schedule_scc
../../gcc/gcc/tree-vect-slp.cc:10189
0x1a912d3 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
../../gcc/gcc/tree-vect-slp.cc:10353
0x1a5166e vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc/gcc/tree-vect-loop.cc:12404
0x1ab04f3 vect_transform_loops
../../gcc/gcc/tree-vectorizer.cc:1007
0x1ab0c95 try_vectorize_loop_1
../../gcc/gcc/tree-vectorizer.cc:1153
0x1ab0dee try_vectorize_loop
../../gcc/gcc/tree-vectorizer.cc:1183
0x1ab10d8 execute
../../gcc/gcc/tree-vectorizer.cc:1299
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.
Similar to PR116142, the problem is a missing vect_reduction_def. In the call
trace:
(gdb) bt
#0 supportable_widening_operation (vinfo=0x33a5b60, code=...,
stmt_info=0x3487ee0, vectype_out=0x7ffff595a1f8,
vectype_in=0x7ffff595a000, code1=0x7fffffffcb70, code2=0x7fffffffcb74,
multi_step_cvt=0x7fffffffcb80, interm_types=0x7fffffffcc28)
at ../../gcc/gcc/tree-vect-stmts.cc:14197
#1 0x00000000019f95ef in vectorizable_conversion (vinfo=0x33a5b60,
stmt_info=0x3487ee0, gsi=0x7fffffffcf60, vec_stmt=0x7fffffffce50,
slp_node=0x3440c30, cost_vec=0x0) at ../../gcc/gcc/tree-vect-stmts.cc:5438
#2 0x0000000001a190fa in vect_transform_stmt (vinfo=0x33a5b60,
stmt_info=0x3487ee0, gsi=0x7fffffffcf60, slp_node=0x3440c30,
slp_node_instance=0x3300660) at ../../gcc/gcc/tree-vect-stmts.cc:13394
... ...
(gdb) call debug_gimple_stmt(use_stmt_info->stmt)
ret_9 = _5 + ret_13;
(gdb) p STMT_VINFO_DEF_TYPE (use_stmt_info)
$2 = vect_internal_def
But in a previous supportable_widening_operation call, the same stmt is
vect_reduction_def:
(gdb) bt
#0 supportable_widening_operation (vinfo=0x33a5b60, code=...,
stmt_info=0x3487620, vectype_out=0x7ffff595a1f8,
vectype_in=0x7ffff595a000, code1=0x7fffffffd000, code2=0x7fffffffd000,
multi_step_cvt=0x7fffffffd004, interm_types=0x7fffffffd010)
at ../../gcc/gcc/tree-vect-stmts.cc:14197
#1 0x000000000284387e in vect_recog_widen_op_pattern (vinfo=0x33a5b60,
last_stmt_info=0x3487620, type_out=0x7fffffffd170, orig_code=MULT_EXPR,
wide_code=..., shift_p=false,
name=0x2d4dfb4 "vect_recog_widen_mult_pattern")
at ../../gcc/gcc/tree-vect-patterns.cc:1658
#2 0x0000000002843a5e in vect_recog_widen_mult_pattern (vinfo=0x33a5b60,
last_stmt_info=0x3487620, type_out=0x7fffffffd170)
at ../../gcc/gcc/tree-vect-patterns.cc:1690
#3 0x000000000285958a in vect_pattern_recog_1 (vinfo=0x33a5b60,
recog_func=..., stmt_info=0x3487620)
at ../../gcc/gcc/tree-vect-patterns.cc:7539
#4 0x00000000028597a2 in vect_pattern_recog (vinfo=0x33a5b60)
at ../../gcc/gcc/tree-vect-patterns.cc:7660
#5 0x0000000001a2f713 in vect_analyze_loop_2 (loop_vinfo=0x33a5b60,
fatal=@0x7fffffffd538: true, suggested_unroll_factor=0x0,
slp_done_for_suggested_uf=@0x7fffffffd45e: true)
at ../../gcc/gcc/tree-vect-loop.cc:2795
#6 0x0000000001a31d69 in vect_analyze_loop_1 (loop=0x7ffff5642130,
shared=0x7fffffffd7b0, loop_form_info=0x7fffffffd5b0, main_loop_vinfo=0x0,
vector_modes=..., mode_i=@0x7fffffffd540: 0,
autodetected_vector_mode=@0x7fffffffd53c: E_VOIDmode,
fatal=@0x7fffffffd538: true) at ../../gcc/gcc/tree-vect-loop.cc:3505
#7 0x0000000001a326f0 in vect_analyze_loop (loop=0x7ffff5642130,
shared=0x7fffffffd7b0) at ../../gcc/gcc/tree-vect-loop.cc:3642
#8 0x0000000001ab085d in try_vectorize_loop_1 (
simduid_to_vf_htab=@0x7fffffffd870: 0x0,
num_vectorized_loops=0x7fffffffd860, loop=0x7ffff5642130,
loop_vectorized_call=0x0, loop_dist_alias_call=0x0, fun=0x7ffff563e000)
at ../../gcc/gcc/tree-vectorizer.cc:1067
#9 0x0000000001ab0def in try_vectorize_loop (
simduid_to_vf_htab=@0x7fffffffd870: 0x0,
num_vectorized_loops=0x7fffffffd860, loop=0x7ffff5642130,
fun=0x7ffff563e000) at ../../gcc/gcc/tree-vectorizer.cc:1183
... ...
(gdb) call debug_gimple_stmt(use_stmt_info->stmt)
ret_9 = _5 + ret_13;
(gdb) p STMT_VINFO_DEF_TYPE (use_stmt_info)
$2 = vect_reduction_def
I've not successfully reproduced the issue with unmodified GCC (and/or a
different target) as at now.
