public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/110109] New: RISC-V: ICE when build the Intrinsic code
@ 2023-06-04 1:47 pan2.li at intel dot com
2023-06-04 1:56 ` [Bug target/110109] " pan2.li at intel dot com
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: pan2.li at intel dot com @ 2023-06-04 1:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/110109] RISC-V: ICE when build the Intrinsic code
2023-06-04 1:47 [Bug c/110109] New: RISC-V: ICE when build the Intrinsic code pan2.li at intel dot com
@ 2023-06-04 1:56 ` pan2.li at intel dot com
2023-06-04 3:58 ` juzhe.zhong at rivai dot ai
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: pan2.li at intel dot com @ 2023-06-04 1:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/110109] RISC-V: ICE when build the Intrinsic code
2023-06-04 1:47 [Bug c/110109] New: RISC-V: ICE when build the Intrinsic code pan2.li at intel dot com
2023-06-04 1:56 ` [Bug target/110109] " pan2.li at intel dot com
@ 2023-06-04 3:58 ` juzhe.zhong at rivai dot ai
2023-06-04 14:03 ` cvs-commit at gcc dot gnu.org
2023-06-04 15:48 ` law at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-06-04 3:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/110109] RISC-V: ICE when build the Intrinsic code
2023-06-04 1:47 [Bug c/110109] New: RISC-V: ICE when build the Intrinsic code pan2.li at intel dot com
2023-06-04 1:56 ` [Bug target/110109] " pan2.li at intel dot com
2023-06-04 3:58 ` juzhe.zhong at rivai dot ai
@ 2023-06-04 14:03 ` cvs-commit at gcc dot gnu.org
2023-06-04 15:48 ` law at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-04 14:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/110109] RISC-V: ICE when build the Intrinsic code
2023-06-04 1:47 [Bug c/110109] New: RISC-V: ICE when build the Intrinsic code pan2.li at intel dot com
` (2 preceding siblings ...)
2023-06-04 14:03 ` cvs-commit at gcc dot gnu.org
@ 2023-06-04 15:48 ` law at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: law at gcc dot gnu.org @ 2023-06-04 15:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-06-04 15:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-04 1:47 [Bug c/110109] New: RISC-V: ICE when build the Intrinsic code pan2.li at intel dot com
2023-06-04 1:56 ` [Bug target/110109] " pan2.li at intel dot com
2023-06-04 3:58 ` juzhe.zhong at rivai dot ai
2023-06-04 14:03 ` cvs-commit at gcc dot gnu.org
2023-06-04 15:48 ` law 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).