https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110119
Bug ID: 110119
Summary: RISC-V: RVV
--param=riscv-autovec-preference=fixed-vlmax ICE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
This following cases:
#include "riscv_vector.h"
typedef int8_t vnx2qi __attribute__ ((vector_size (2)));
__attribute__ ((noipa)) vnx2qi
f_vnx2qi (int8_t a, int8_t b, int8_t *out)
{
vnx2qi v = {a, b};
return v;
}
__attribute__ ((noipa)) vnx2qi
f_vnx2qi_2 (vnx2qi a, int8_t *out)
{
return a;
}
__attribute__ ((noipa)) vint32m1_t
f_vint32m1 (int8_t * a, int8_t *out)
{
vint32m1_t v = *(vint32m1_t*)a;
return v;
}
are all causing ICE:
0x1667a6d crash_signal
../../../riscv-gcc/gcc/toplev.cc:314
0x10a476c hard_function_value(tree_node const*, tree_node const*, tree_node
const*, int)
../../../riscv-gcc/gcc/explow.cc:2258
0x116f092 aggregate_value_p(tree_node const*, tree_node const*)
../../../riscv-gcc/gcc/function.cc:2126
0x117938e allocate_struct_function(tree_node*, bool)
../../../riscv-gcc/gcc/function.cc:4831
0xd0c7b7 store_parm_decls()
../../../riscv-gcc/gcc/c/c-decl.cc:10743
0xd7811e c_parser_declaration_or_fndef
../../../riscv-gcc/gcc/c/c-parser.cc:2805
0xd75ea7 c_parser_external_declaration
../../../riscv-gcc/gcc/c/c-parser.cc:1925
0xd7592e c_parser_translation_unit
../../../riscv-gcc/gcc/c/c-parser.cc:1779
0xdc1d2b c_parse_file()
../../../riscv-gcc/gcc/c/c-parser.cc:24657
0xe5f20b c_common_parse_file()
../../../riscv-gcc/gcc/c-family/c-opts.cc:1248
The reason of this ICE is because this walkaround code:
/* TODO: Currently, it will cause an ICE for --param
riscv-autovec-preference=fixed-vlmax. So, we just return NULL_RTX here
let GCC generate loads/stores. Ideally, we should either warn the user not
to use an RVV vector type as function argument or support the calling
convention directly. */
if (riscv_v_ext_mode_p (mode))
return NULL_RTX;
in riscv_get_arg_info.
>From my experience (my local downstream GCC doesn't have such issue), I am
100% sure that such issue will be addressed when we support vector calling
convention in GCC.
And we already have calling convention in "rvv-next" branch, there is no
difference between "rvv-next" and my internal downstream RVV GCC.
The calling convention implementation of "rvv-next" is totally same as LLVM.
However, the calling convention is not ratified yet.
I don't have time to figure out the approach without supporting calling
convention and I don't think we need this approach.
I believe we will ultimately remove this approach (without supporting calling
convention) since we will have vector calling convention.
Also, this ICE only happens when we specify
--param=riscv-autovec-preference=fixed-vlmax
Base on these circumstances, I suggest we support vector calling convention and
enable it when --param=riscv-autovec-preference=fixed-vlmax is enable.
I think such GCC internal compile option to enable vector calling convention
doesn't break the RISC-V standard.
Any suggestions?
