https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
Bug ID: 110751
Summary: RISC-V: Suport undefined value that allows VSETVL PASS
use TA/MA
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xuli1 at eswincomputing dot com
Target Milestone: ---
Created attachment 55588
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55588&action=edit
testcase
Zhong has merged two auto-vectorization patches:
https://github.com/gcc-mirror/gcc/commit/0d4dd7e07a879d6c07a33edb2799710faa95651e
https://github.com/gcc-mirror/gcc/commit/44f244e4672578be6cc513104473981790a1c164
Consider this following case:
#include <stdint-gcc.h>
__attribute__((noipa))
void vrem_int8_t (int8_t * __restrict dst, int8_t * __restrict a, int8_t *
__restrict b, int n)
{
for (int i = 0; i < n; i++)
dst[i] = a[i] % b[i];
}
vrem_int8_t:
ble a3,zero,.L5
.L3:
vsetvli a5,a3,e8,m1,tu,ma --> tu here
vle8.v v1,0(a1)
vle8.v v2,0(a2)
sub a3,a3,a5
vrem.vv v1,v1,v2
vse8.v v1,0(a0)
add a1,a1,a5
add a2,a2,a5
add a0,a0,a5
bne a3,zero,.L3
.L5:
ret
Currently, the return value of TARGET_PREFERRED_ELSE_VALUE targethook is not
ideal for RVV since it will let VSETVL PASS use MU or TU. We want to suport
undefined value that allows VSETVL PASS use TA/MA.
According to Zhong's advice, there are two approachs:
1.Add a new tree code representing undefined value, like
DEFTREECODE (UNDEF_TYPE, "undef_type", tcc_type, 0).
2.Modify the targethook TARGET_PREFERRED_ELSE_VALUE to support passing in a GSI
parameter. (Currently only the aarch64 and riscv architectures implement this
hook), In this way, we can build an RVV intrinsic __riscv_vundefine in the
RISCV backend, so that the backend can automatically recognize undefine and use
TA in VSETVL instruction.
Which approach is better? Looking forward to your advice, thanks.
