[Bug tree-optimization/116314] New: ICE after fixing PR116142 and implementing vec_widen_smult_{odd,even}_M for LoongArch

xry111 at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Aug 9 11:48:09 GMT 2024


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.


More information about the Gcc-bugs mailing list