[Bug c/110109] New: RISC-V: ICE when build the Intrinsic code

[Bug c/110109] New: RISC-V: ICE when build the Intrinsic code

[pan2.li at intel dot com]

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

            Bug ID: 110109
           Summary: RISC-V: ICE when build the Intrinsic code
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pan2.li at intel dot com
  Target Milestone: ---

Created attachment 55251
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55251&action=edit
Example code for reproducing

There will be one ICE when build below code with option similar to
'/_INSTALL_RISC-V/bin/riscv64-unknown-elf-gcc -march=rv64gcv -O3 tmp.c -c -S -o
-'

#include "riscv_vector.h"

void __attribute__ ((noinline, noclone))
clean_subreg (int32_t *in, int32_t *out, size_t m)
{
  vint16m8_t v24, v8, v16;
  vint32m8_t result = __riscv_vle32_v_i32m8 (in, 32);
  vint32m1_t v0 = __riscv_vget_v_i32m8_i32m1 (result, 0);
  vint32m1_t v1 = __riscv_vget_v_i32m8_i32m1 (result, 1);
  vint32m1_t v2 = __riscv_vget_v_i32m8_i32m1 (result, 2);
  vint32m1_t v3 = __riscv_vget_v_i32m8_i32m1 (result, 3);
  vint32m1_t v4 = __riscv_vget_v_i32m8_i32m1 (result, 4);
  vint32m1_t v5 = __riscv_vget_v_i32m8_i32m1 (result, 5);
  vint32m1_t v6 = __riscv_vget_v_i32m8_i32m1 (result, 6);
  vint32m1_t v7 = __riscv_vget_v_i32m8_i32m1 (result, 7);

  for (size_t i = 0; i < m; i++)
  {
    v0 = __riscv_vadd_vv_i32m1(v0, v0, 4);
    v1 = __riscv_vadd_vv_i32m1(v1, v1, 4);
    v2 = __riscv_vadd_vv_i32m1(v2, v2, 4);
    v3 = __riscv_vadd_vv_i32m1(v3, v3, 4);
    v4 = __riscv_vadd_vv_i32m1(v4, v4, 4);
    v5 = __riscv_vadd_vv_i32m1(v5, v5, 4);
    v6 = __riscv_vadd_vv_i32m1(v6, v6, 4);
    v7 = __riscv_vadd_vv_i32m1(v7, v7, 4);
  }

  vint32m8_t result2;

  result2 = __riscv_vset_v_i32m1_i32m8 (result2, 0, v0);
  result2 = __riscv_vset_v_i32m1_i32m8 (result2, 1, v1);
  result2 = __riscv_vset_v_i32m1_i32m8 (result2, 2, v2);
  result2 = __riscv_vset_v_i32m1_i32m8 (result2, 3, v3);
  result2 = __riscv_vset_v_i32m1_i32m8 (result2, 4, v4);
  result2 = __riscv_vset_v_i32m1_i32m8 (result2, 5, v5);
  result2 = __riscv_vset_v_i32m1_i32m8 (result2, 6, v6);
  result2 = __riscv_vset_v_i32m1_i32m8 (result2, 7, v7);

  __riscv_vse32_v_i32m8((int8_t *)(out), result2, 64);
 }

Then we will have ICE as below.

        .file   "tmp.c"
        .option nopic
        .attribute arch,
"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0"
        .attribute unaligned_access, 0
        .attribute stack_align, 16
tmp.c: In function ‘clean_subreg’:
tmp.c:40:25: warning: passing argument 1 of ‘__riscv_vse32_v_i32m8’ from
incompatible pointer type [-Wincompatible-pointer-types]
   40 |   __riscv_vse32_v_i32m8((int8_t *)(out), result2, 64);
      |                         ^~~~~~~~~~~~~~~
      |                         |
      |                         int8_t * {aka signed char *}
In file included from tmp.c:1:
/home/pli/repos/gcc/111/riscv-gnu-toolchain/_INSTALL_RISC-V/lib/gcc/riscv64-unknown-elf/14.0.0/include/riscv_vector.h:94:9:
note: expected ‘int *’ but argument is of type ‘int8_t *’ {aka ‘signed char *’}
   94 | #pragma riscv intrinsic "vector"
      |         ^~~~~
        .text
during RTL pass: vregs
tmp.c:41:2: internal compiler error: in to_constant, at poly-int.h:504
   41 |  }
      |  ^
0xf22120 poly_int_pod<2u, unsigned short>::to_constant() const
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/poly-int.h:504
0x26fb2fb pattern57
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/gcc/insn-recog.cc:4694
0x2863074 recog_410
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/config/riscv/iterators.md:74
0x28901ec recog_440
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/config/riscv/riscv.md:1621
0x2891f11 recog(rtx_def*, rtx_insn*, int*)
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/config/riscv/iterators.md:52
0xf278e7 recog_memoized(rtx_insn*)
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/recog.h:273
0x15dbaca extract_insn(rtx_insn*)
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/recog.cc:2789
0x11a2edc instantiate_virtual_regs_in_insn
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/function.cc:1611
0x11a4501 instantiate_virtual_regs
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/function.cc:1984
0x11a45e8 execute
       
/home/pli/repos/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/function.cc:2033
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.

[Bug target/110109] RISC-V: ICE when build the Intrinsic code

[pan2.li at intel dot com]

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

--- Comment #1 from Li Pan <pan2.li at intel dot com> ---
GCC 13 doesn't have this issue.

[Bug target/110109] RISC-V: ICE when build the Intrinsic code

[juzhe.zhong at rivai dot ai]

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

--- Comment #2 from JuzheZhong <juzhe.zhong at rivai dot ai> ---

(define_insn_and_split "*vlmul_extx2<mode>"
  [(set (match_operand:<VLMULX2> 0 "register_operand"  "=vr, ?&vr")
        (subreg:<VLMULX2>
          (match_operand:VLMULEXT2 1 "register_operand" " 0,   vr") 0))]
  "TARGET_VECTOR"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  emit_insn (gen_rtx_SET (gen_lowpart (<MODE>mode, operands[0]), operands[1]));
  DONE;
})

(define_insn_and_split "*vlmul_extx4<mode>"
  [(set (match_operand:<VLMULX4> 0 "register_operand"  "=vr, ?&vr")
        (subreg:<VLMULX4>
          (match_operand:VLMULEXT4 1 "register_operand" " 0,   vr") 0))]
  "TARGET_VECTOR"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  emit_insn (gen_rtx_SET (gen_lowpart (<MODE>mode, operands[0]), operands[1]));
  DONE;
})

(define_insn_and_split "*vlmul_extx8<mode>"
  [(set (match_operand:<VLMULX8> 0 "register_operand"  "=vr, ?&vr")
        (subreg:<VLMULX8>
          (match_operand:VLMULEXT8 1 "register_operand" " 0,   vr") 0))]
  "TARGET_VECTOR"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  emit_insn (gen_rtx_SET (gen_lowpart (<MODE>mode, operands[0]), operands[1]));
  DONE;
})

(define_insn_and_split "*vlmul_extx16<mode>"
  [(set (match_operand:<VLMULX16> 0 "register_operand"  "=vr, ?&vr")
        (subreg:<VLMULX16>
          (match_operand:VLMULEXT16 1 "register_operand" " 0,   vr") 0))]
  "TARGET_VECTOR"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  emit_insn (gen_rtx_SET (gen_lowpart (<MODE>mode, operands[0]), operands[1]));
  DONE;
})

(define_insn_and_split "*vlmul_extx32<mode>"
  [(set (match_operand:<VLMULX32> 0 "register_operand"  "=vr, ?&vr")
        (subreg:<VLMULX32>
          (match_operand:VLMULEXT32 1 "register_operand" " 0,   vr") 0))]
  "TARGET_VECTOR"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  emit_insn (gen_rtx_SET (gen_lowpart (<MODE>mode, operands[0]), operands[1]));
  DONE;
})

(define_insn_and_split "*vlmul_extx64<mode>"
  [(set (match_operand:<VLMULX64> 0 "register_operand"  "=vr, ?&vr")
        (subreg:<VLMULX64>
          (match_operand:VLMULEXT64 1 "register_operand" " 0,   vr") 0))]
  "TARGET_VECTOR"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  emit_insn (gen_rtx_SET (gen_lowpart (<MODE>mode, operands[0]), operands[1]));
  DONE;
})

I realize when I removed these patterns, issue is fixed.

I am not sure whether it is correct fix since these patterns are existing in
GCC13 which doesn't have such issue.

The reason I add this patterns since GCC can not well handle subreg, If I
simpily
use emit_insn (gen_rtx_SET (gen_lowpart (<MODE>mode, operands[0]),
operands[1])); 
in "expand" stage, it can not assign regno(operands[0]) == regno (operands[1])
in
RA, so I use constraint to force it.

These patterns are performance optimization patterns. Should I remove those
patterns and just use 
emit_insn (gen_rtx_SET (gen_lowpart (<MODE>mode, operands[0]), operands[1]));
in "expand" stage to fix this issue even though it demage the performance.

[Bug target/110109] RISC-V: ICE when build the Intrinsic code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pan Li <panli@gcc.gnu.org>:

https://gcc.gnu.org/g:a96ba6b958a00ad59c43cae10be65b263b5d0d2d

commit r14-1531-ga96ba6b958a00ad59c43cae10be65b263b5d0d2d
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date:   Sun Jun 4 16:51:47 2023 +0800

    RISC-V: Remove redundant vlmul_ext_* patterns to fix PR110109

    This patch is to fix PR110109 issue. This issue happens is because:

    (define_insn_and_split "*vlmul_extx2<mode>"
      [(set (match_operand:<VLMULX2> 0 "register_operand"  "=vr, ?&vr")
           (subreg:<VLMULX2>
             (match_operand:VLMULEXT2 1 "register_operand" " 0,   vr") 0))]
      "TARGET_VECTOR"
      "#"
      "&& reload_completed"
      [(const_int 0)]
    {
      emit_insn (gen_rtx_SET (gen_lowpart (<MODE>mode, operands[0]),
operands[1]));
      DONE;
    })

    Such pattern generate such codes in insn-recog.cc:
    static int
    pattern57 (rtx x1)
    {
      rtx * const operands ATTRIBUTE_UNUSED = &recog_data.operand[0];
      rtx x2;
      int res ATTRIBUTE_UNUSED;
      if (maybe_ne (SUBREG_BYTE (x1).to_constant (), 0))
        return -1;
    ...

    PR110109 ICE at maybe_ne (SUBREG_BYTE (x1).to_constant (), 0) since for
scalable
    RVV modes can not be accessed as SUBREG_BYTE (x1).to_constant ()

    I create that patterns is to optimize the following test:
    vfloat32m2_t test_vlmul_ext_v_f32mf2_f32m2(vfloat32mf2_t op1) {
      return __riscv_vlmul_ext_v_f32mf2_f32m2(op1);
    }

    codegen:
    test_vlmul_ext_v_f32mf2_f32m2:
            vsetvli a5,zero,e32,m2,ta,ma
            vmv.v.i v2,0
            vsetvli a5,zero,e32,mf2,ta,ma
            vle32.v v2,0(a1)
            vs2r.v  v2,0(a0)
            ret

    There is a redundant 'vmv.v.i' here, Since GCC doesn't undefine IR
    (unlike LLVM, LLVM has undef/poison).  For vlmul_ext_* RVV intrinsic,
    GCC will initiate all zeros into register. However, I think it's not
    a big issue after we support subreg livness tracking.

            PR target/110109

    gcc/ChangeLog:

            * config/riscv/riscv-vector-builtins-bases.cc: Change expand
approach.
            * config/riscv/vector.md (@vlmul_extx2<mode>): Remove it.
            (@vlmul_extx4<mode>): Ditto.
            (@vlmul_extx8<mode>): Ditto.
            (@vlmul_extx16<mode>): Ditto.
            (@vlmul_extx32<mode>): Ditto.
            (@vlmul_extx64<mode>): Ditto.
            (*vlmul_extx2<mode>): Ditto.
            (*vlmul_extx4<mode>): Ditto.
            (*vlmul_extx8<mode>): Ditto.
            (*vlmul_extx16<mode>): Ditto.
            (*vlmul_extx32<mode>): Ditto.
            (*vlmul_extx64<mode>): Ditto.

    gcc/testsuite/ChangeLog:

            * gcc.target/riscv/rvv/base/pr110109-1.c: New test.
            * gcc.target/riscv/rvv/base/pr110109-2.c: New test.

[Bug target/110109] RISC-V: ICE when build the Intrinsic code

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |law at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #4 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Should be fixed on the trunk.