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