public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/110265] New: RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d"
@ 2023-06-15  7:44 pan2.li at intel dot com
  2023-06-15  7:59 ` [Bug c/110265] RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13 juzhe.zhong at rivai dot ai
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: pan2.li at intel dot com @ 2023-06-15  7:44 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 110265
           Summary: RISC-V: ICE when build RVV intrinsic with
                    "-march=rv32gc_zve64d -mabi=ilp32d"
           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 55325
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55325&action=edit
Reproduce source code

Given we have the below code.

#include "riscv_vector.h"

vint16m1_t test_vredmax_vs_i16mf4_i16m1(vint16mf4_t vector, vint16m1_t scalar,
size_t vl) {
  return __riscv_vredmax_vs_i16mf4_i16m1(vector, scalar, vl);
}

There will be the ICE when build similar as "riscv64-unknown-elf-gcc
-march=rv32gc_zve64d -mabi=ilp32d -O3 -Wno-psabi test-int.c  -c -S -o -".

>> ../__RISC-V_INSTALL_/bin/riscv64-unknown-elf-gcc -march=rv32gc_zve64d -mabi=ilp32d -O3 -Wno-psabi test-int.c  -c -S -o -
        .file   "test-int.c"
        .option nopic
        .attribute arch,
"rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl32b1p0_zvl64b1p0"
        .attribute unaligned_access, 0
        .attribute stack_align, 16
        .text
test-int.c: In function ‘test_vredmax_vs_i16mf4_i16m1’:
test-int.c:4:10: error: invalid argument to built-in function
    4 |   return __riscv_vredmax_vs_i16mf4_i16m1(vector, scalar, vl);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
during RTL pass: expand
test-int.c:4:10: internal compiler error: Segmentation fault
0x16e7017 crash_signal
       
/home/pli/repos/gcc/333/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/toplev.cc:314
0x7f9dcf04251f ???
        ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x111b9fa store_expr(tree_node*, rtx_def*, int, bool, bool)
       
/home/pli/repos/gcc/333/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/expr.cc:6352
0x1119e77 expand_assignment(tree_node*, tree_node*, bool)
       
/home/pli/repos/gcc/333/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/expr.cc:6048
0xf64d2c expand_call_stmt
       
/home/pli/repos/gcc/333/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/cfgexpand.cc:2829
0xf68ac6 expand_gimple_stmt_1
       
/home/pli/repos/gcc/333/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/cfgexpand.cc:3880
0xf691b3 expand_gimple_stmt
       
/home/pli/repos/gcc/333/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/cfgexpand.cc:4044
0xf71d20 expand_gimple_basic_block
       
/home/pli/repos/gcc/333/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/cfgexpand.cc:6096
0xf74279 execute
       
/home/pli/repos/gcc/333/riscv-gnu-toolchain/gcc/__RISC-V_BUILD/../gcc/cfgexpand.cc:6831

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c/110265] RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.
  2023-06-15  7:44 [Bug c/110265] New: RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d" pan2.li at intel dot com
@ 2023-06-15  7:59 ` juzhe.zhong at rivai dot ai
  2023-06-16 23:37 ` [Bug c/110265] RISC-V: ICE when build RVV intrinsic integer reduction " cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-06-15  7:59 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
This issue is caused by incorrect redcution instructions:

(define_insn "@pred_reduc_<reduc><mode><vlmul1>"
  [(set (match_operand:<VLMUL1> 0 "register_operand"            "=vr,   vr")
        (unspec:<VLMUL1>
          [(unspec:<VM>
             [(match_operand:<VM> 1 "vector_mask_operand"     "vmWc1,vmWc1")
              (match_operand 5 "vector_length_operand"        "   rK,   rK")
              (match_operand 6 "const_int_operand"            "    i,    i")
              (match_operand 7 "const_int_operand"            "    i,    i")
              (reg:SI VL_REGNUM)
              (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
           (any_reduc:VI
             (vec_duplicate:VI
               (vec_select:<VEL>
                 (match_operand:<VLMUL1> 4 "register_operand" "   vr,   vr")
                 (parallel [(const_int 0)])))
             (match_operand:VI 3 "register_operand"           "   vr,   vr"))
           (match_operand:<VLMUL1> 2 "vector_merge_operand"   "   vu,    0")]
UNSPEC_REDUC))]
  "TARGET_VECTOR && TARGET_MIN_VLEN >= 128"
  "vred<reduc>.vs\t%0,%3,%4%p1"
  [(set_attr "type" "vired")
   (set_attr "mode" "<MODE>")])

(define_insn "@pred_reduc_<reduc><mode><vlmul1_zve64>"
  [(set (match_operand:<VLMUL1_ZVE64> 0 "register_operand"            "=vr,  
vr")
        (unspec:<VLMUL1_ZVE64>
          [(unspec:<VM>
             [(match_operand:<VM> 1 "vector_mask_operand"     "vmWc1,vmWc1")
              (match_operand 5 "vector_length_operand"        "   rK,   rK")
              (match_operand 6 "const_int_operand"            "    i,    i")
              (match_operand 7 "const_int_operand"            "    i,    i")
              (reg:SI VL_REGNUM)
              (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
           (any_reduc:VI_ZVE64
             (vec_duplicate:VI_ZVE64
               (vec_select:<VEL>
                 (match_operand:<VLMUL1_ZVE64> 4 "register_operand" "   vr,  
vr")
                 (parallel [(const_int 0)])))
             (match_operand:VI_ZVE64 3 "register_operand"           "   vr,  
vr"))
           (match_operand:<VLMUL1_ZVE64> 2 "vector_merge_operand"   "   vu,   
0")] UNSPEC_REDUC))]
  "TARGET_VECTOR && TARGET_MIN_VLEN == 64"
  "vred<reduc>.vs\t%0,%3,%4%p1"
  [(set_attr "type" "vired")
   (set_attr "mode" "<MODE>")])

(define_insn "@pred_reduc_<reduc><mode><vlmul1_zve32>"
  [(set (match_operand:<VLMUL1_ZVE32> 0 "register_operand"          "=vd, vd,
vr, vr")
        (unspec:<VLMUL1_ZVE32>
          [(unspec:<VM>
             [(match_operand:<VM> 1 "vector_mask_operand"           " vm,
vm,Wc1,Wc1")
              (match_operand 5 "vector_length_operand"              " rK, rK,
rK, rK")
              (match_operand 6 "const_int_operand"                  "  i,  i, 
i,  i")
              (match_operand 7 "const_int_operand"                  "  i,  i, 
i,  i")
              (reg:SI VL_REGNUM)
              (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
           (any_reduc:VI_ZVE32
             (vec_duplicate:VI_ZVE32
               (vec_select:<VEL>
                 (match_operand:<VLMUL1_ZVE32> 4 "register_operand" " vr, vr,
vr, vr")
                 (parallel [(const_int 0)])))
             (match_operand:VI_ZVE32 3 "register_operand"           " vr, vr,
vr, vr"))
           (match_operand:<VLMUL1_ZVE32> 2 "vector_merge_operand"   " vu,  0,
vu,  0")] UNSPEC_REDUC))]
  "TARGET_VECTOR && TARGET_MIN_VLEN == 32"
  "vred<reduc>.vs\t%0,%3,%4%p1"
  [(set_attr "type" "vired")
   (set_attr "mode" "<MODE>")])


This 3 patterns are using same iterators, but different attributes.

For example, for VNx1QI reduction.

The first pattern is pred_reduc_sumvnx1qivnx16qi (since vnx16qi is the LMUL =
1mode for TARGET_MIN_VLEN >= 128).

The first pattern is pred_reduc_sumvnx1qivnx8qi (since vnx8qi is the LMUL =
1mode for TARGET_MIN_VLEN == 64).

The first pattern is pred_reduc_sumvnx1qivnx4qi (since vnx4qi is the LMUL =
1mode for TARGET_MIN_VLEN == 32).

Even though their patterns name are different, but share same iterators same
code_for

They are all using code_for_reduc (UNSPEC, vnx1qi).
We can't differentiate them.

So the idea should be merge them into same pattern:

(define_mode_iterator VQI [
  (VNx1QI "TARGET_MIN_VLEN < 128") VNx2QI VNx4QI VNx8QI VNx16QI VNx32QI
(VNx64QI "TARGET_MIN_VLEN > 32") (VNx128QI "TARGET_MIN_VLEN >= 128")
])

(define_mode_iterator VQI_LMUL1 [
  (VNx16QI "TARGET_MIN_VLEN >= 128") (VNx8QI "TARGET_MIN_VLEN == 64") (VNx4QI
"TARGET_MIN_VLEN == 32")
])

(define_insn "@pred_reduc_<reduc><VQI:mode><VQI_LMUL1:mode>"
  [(set (match_operand:VQI_LMUL1 0 "register_operand"            "=vr,   vr")
  (unspec:VQI_LMUL1
    [(unspec:<VM>
       [(match_operand:<VM> 1 "vector_mask_operand"     "vmWc1,vmWc1")
        (match_operand 5 "vector_length_operand"        "   rK,   rK")
        (match_operand 6 "const_int_operand"            "    i,    i")
        (match_operand 7 "const_int_operand"            "    i,    i")
        (reg:SI VL_REGNUM)
        (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
     (any_reduc:VQI
       (vec_duplicate:VQI
         (vec_select:<VEL>
           (match_operand:VQI_LMUL1 4 "register_operand" "   vr,   vr")
           (parallel [(const_int 0)])))
       (match_operand:VQI 3 "register_operand"           "   vr,   vr"))
     (match_operand:VQI_LMUL1 2 "vector_merge_operand"   "   vu,    0")]
UNSPEC_REDUC))]
  "TARGET_VECTOR"
  "vred<reduc>.vs\t%0,%3,%4%p1"
  [(set_attr "type" "vired")
   (set_attr "mode" "<VQI:MODE>")])

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c/110265] RISC-V: ICE when build RVV intrinsic integer reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.
  2023-06-15  7:44 [Bug c/110265] New: RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d" pan2.li at intel dot com
  2023-06-15  7:59 ` [Bug c/110265] RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13 juzhe.zhong at rivai dot ai
@ 2023-06-16 23:37 ` cvs-commit at gcc dot gnu.org
  2024-01-18  3:01 ` [Bug target/110265] " pan2.li at intel dot com
  2024-01-20 17:24 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-16 23:37 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 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:d0cf0c6c8449009697ad29dd7cb60e7f655628f2

commit r14-1899-gd0cf0c6c8449009697ad29dd7cb60e7f655628f2
Author: Pan Li <pan2.li@intel.com>
Date:   Fri Jun 16 15:01:46 2023 +0800

    RISC-V: Bugfix for RVV integer reduction in ZVE32/64.

    The rvv integer reduction has 3 different patterns for zve128+, zve64
    and zve32. They take the same iterator with different attributions.
    However, we need the generated function code_for_reduc (code, mode1,
mode2).
    The implementation of code_for_reduc may look like below.

    code_for_reduc (code, mode1, mode2)
    {
      if (code == max && mode1 == VNx1QI && mode2 == VNx1QI)
        return CODE_FOR_pred_reduc_maxvnx1qivnx16qi; // ZVE128+

      if (code == max && mode1 == VNx1QI && mode2 == VNx1QI)
        return CODE_FOR_pred_reduc_maxvnx1qivnx8qi;  // ZVE64

      if (code == max && mode1 == VNx1QI && mode2 == VNx1QI)
        return CODE_FOR_pred_reduc_maxvnx1qivnx4qi;  // ZVE32
    }

    Thus there will be a problem here. For example zve32, we will have
    code_for_reduc (max, VNx1QI, VNx1QI) which will return the code of
    the ZVE128+ instead of the ZVE32 logically.

    This patch will merge the 3 patterns into pattern, and pass both the
    input_vector and the ret_vector of code_for_reduc. For example, ZVE32 will
be
    code_for_reduc (max, VNx1Q1, VNx8QI), then the correct code of ZVE32
    will be returned as expectation.

    Please note both GCC 13 and 14 are impacted by this issue.

    Signed-off-by: Pan Li <pan2.li@intel.com>
    Co-Authored by: Juzhe-Zhong <juzhe.zhong@rivai.ai>

            PR target/110265

    gcc/ChangeLog:

            * config/riscv/riscv-vector-builtins-bases.cc: Add ret_mode for
            integer reduction expand.
            * config/riscv/vector-iterators.md: Add VQI, VHI, VSI and VDI,
            and the LMUL1 attr respectively.
            * config/riscv/vector.md
            (@pred_reduc_<reduc><mode><vlmul1>): Removed.
            (@pred_reduc_<reduc><mode><vlmul1_zve64>): Likewise.
            (@pred_reduc_<reduc><mode><vlmul1_zve32>): Likewise.
            (@pred_reduc_<reduc><VQI:mode><VQI_LMUL1:mode>): New pattern.
            (@pred_reduc_<reduc><VHI:mode><VHI_LMUL1:mode>): Likewise.
            (@pred_reduc_<reduc><VSI:mode><VSI_LMUL1:mode>): Likewise.
            (@pred_reduc_<reduc><VDI:mode><VDI_LMUL1:mode>): Likewise.

    gcc/testsuite/ChangeLog:

            * gcc.target/riscv/rvv/base/pr110265-1.c: New test.
            * gcc.target/riscv/rvv/base/pr110265-1.h: New test.
            * gcc.target/riscv/rvv/base/pr110265-2.c: New test.
            * gcc.target/riscv/rvv/base/pr110265-2.h: New test.
            * gcc.target/riscv/rvv/base/pr110265-3.c: New test.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug target/110265] RISC-V: ICE when build RVV intrinsic integer reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.
  2023-06-15  7:44 [Bug c/110265] New: RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d" pan2.li at intel dot com
  2023-06-15  7:59 ` [Bug c/110265] RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13 juzhe.zhong at rivai dot ai
  2023-06-16 23:37 ` [Bug c/110265] RISC-V: ICE when build RVV intrinsic integer reduction " cvs-commit at gcc dot gnu.org
@ 2024-01-18  3:01 ` pan2.li at intel dot com
  2024-01-20 17:24 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: pan2.li at intel dot com @ 2024-01-18  3:01 UTC (permalink / raw)
  To: gcc-bugs

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

Li Pan <pan2.li at intel dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Li Pan <pan2.li at intel dot com> ---
Fixed.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug target/110265] RISC-V: ICE when build RVV intrinsic integer reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.
  2023-06-15  7:44 [Bug c/110265] New: RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d" pan2.li at intel dot com
                   ` (2 preceding siblings ...)
  2024-01-18  3:01 ` [Bug target/110265] " pan2.li at intel dot com
@ 2024-01-20 17:24 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-01-20 17:24 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-01-20 17:24 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-15  7:44 [Bug c/110265] New: RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d" pan2.li at intel dot com
2023-06-15  7:59 ` [Bug c/110265] RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13 juzhe.zhong at rivai dot ai
2023-06-16 23:37 ` [Bug c/110265] RISC-V: ICE when build RVV intrinsic integer reduction " cvs-commit at gcc dot gnu.org
2024-01-18  3:01 ` [Bug target/110265] " pan2.li at intel dot com
2024-01-20 17:24 ` pinskia at gcc dot gnu.org

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).