[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #21 from JuzheZhong --- Hi, Richi. Finish and confirm RISC-V regression. All pass. Thank you so much!
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #20 from CVS Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:5255273ee8b14ea565eb43f067a86370d25df114 commit r14-4538-g5255273ee8b14ea565eb43f067a86370d25df114 Author: Juzhe-Zhong Date: Tue Oct 10 20:15:35 2023 +0800 RISC-V: Add VLS BOOL mode vcond_mask[PR111751] Richard patch resolve PR111751: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7c76c876e917a1f20a788f602cc78fff7d0a2a65 which cause ICE in RISC-V regression: FAIL: gcc.dg/torture/pr53144.c -O2 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:328) FAIL: gcc.dg/torture/pr53144.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr53144.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:328) FAIL: gcc.dg/torture/pr53144.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/pr53144.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:328) FAIL: gcc.dg/torture/pr53144.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gcc.dg/torture/pr53144.c -O3 -g (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:328) FAIL: gcc.dg/torture/pr53144.c -O3 -g (test for excess errors) VLS BOOL modes vcond_mask is needed to fix this regression ICE. More details: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 Tested and Committed. PR target/111751 gcc/ChangeLog: * config/riscv/autovec.md: Add VLS BOOL modes.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #19 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:70b5c6981fcdff246f90e57e91f3e1667eab2eb3 commit r14-4537-g70b5c6981fcdff246f90e57e91f3e1667eab2eb3 Author: Richard Biener Date: Tue Oct 10 13:33:34 2023 +0200 tree-optimization/111751 - support 1024 bit vector constant reinterpretation The following ups the limit in fold_view_convert_expr to handle 1024bit vectors as used by GCN and RVV. It also robustifies the handling in visit_reference_op_load to properly give up when constants cannot be re-interpreted. PR tree-optimization/111751 * fold-const.cc (fold_view_convert_expr): Up the buffer size to 128 bytes. * tree-ssa-sccvn.cc (visit_reference_op_load): Special case constants, giving up when re-interpretation to the target type fails.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #18 from JuzheZhong ---
(In reply to Richard Biener from comment #16)
> (In reply to JuzheZhong from comment #14)
> > Also this case ICE:
> >
> > typedef unsigned char __attribute__((vector_size(4))) uvec;
> >
> > int main (int argc, char *argv[]) {
> > int i;
> > int x = 0;
> > uvec uc0 = (uvec) {argc, 1, 2, 10};
> > unsigned char uc1[4] = {0, 3, 2, 200};
> > signed char ucg[4] = {1, 0, 0, 0 };
> > signed char ucl[4] = {0, 1, 0, 1 };
> >
> > #define uc0_ ((unsigned char *))
> >
> > for (i = 0; i < 4; i ++) {
> > x |= ucg[i] != (uc0_[i] > uc1[i]);
> > x |= ucl[i] != (uc0_[i] < uc1[i]);
> > }
> > return x;
> > }
> >
> > during GIMPLE pass: isel
> > dump file: auto.c.256t.isel
> > auto.c: In function 'main':
> > auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
> > gimple-isel.cc:328
> > 3 | int main (int argc, char *argv[]) {
> > | ^~~~
> > 0x1bb55bd gimple_expand_vec_cond_expr
> > ../../../../gcc/gcc/gimple-isel.cc:325
> > 0x1bb57c6 execute
> > ../../../../gcc/gcc/gimple-isel.cc:390
> >
> >
> > Looks odd, it ICE at gimple-isel.cc:
> >
> > gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
>
> I have a fix for the first issue. For this one the issue seems to be that
> we do have vec_cmp for _2 > { 0, 3, 2, 200 } when doing instruction
> selection for
>
> mask__11.18_97 = VEC_COND_EXPR 0, 0 }>;
>
> note the value is of vector boolean type. But we fail to have
> vcond_maskV4BIV4BI.
>
> ISTR we have fixed sth similar
> by adding missing patterns with VnBImode result? But maybe forgot about
> VLS modes here?
Confirm the second issue is fixed after I added vcond_mask of VLS BOOL mask
mode
I will commit it after I finish RISC-V regression.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #17 from CVS Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:a704603d458b1e55b561ddfb4e513581ee863ed6 commit r14-4528-ga704603d458b1e55b561ddfb4e513581ee863ed6 Author: Juzhe-Zhong Date: Tue Oct 10 19:47:06 2023 +0800 RISC-V: Add testcase for SCCVN optimization[PR111751] Add testcase for PR111751 which has been fixed: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632474.html PR target/111751 gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr111751.c: New test.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #16 from Richard Biener ---
(In reply to JuzheZhong from comment #14)
> Also this case ICE:
>
> typedef unsigned char __attribute__((vector_size(4))) uvec;
>
> int main (int argc, char *argv[]) {
> int i;
> int x = 0;
> uvec uc0 = (uvec) {argc, 1, 2, 10};
> unsigned char uc1[4] = {0, 3, 2, 200};
> signed char ucg[4] = {1, 0, 0, 0 };
> signed char ucl[4] = {0, 1, 0, 1 };
>
> #define uc0_ ((unsigned char *))
>
> for (i = 0; i < 4; i ++) {
> x |= ucg[i] != (uc0_[i] > uc1[i]);
> x |= ucl[i] != (uc0_[i] < uc1[i]);
> }
> return x;
> }
>
> during GIMPLE pass: isel
> dump file: auto.c.256t.isel
> auto.c: In function 'main':
> auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
> gimple-isel.cc:328
> 3 | int main (int argc, char *argv[]) {
> | ^~~~
> 0x1bb55bd gimple_expand_vec_cond_expr
> ../../../../gcc/gcc/gimple-isel.cc:325
> 0x1bb57c6 execute
> ../../../../gcc/gcc/gimple-isel.cc:390
>
>
> Looks odd, it ICE at gimple-isel.cc:
>
> gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
I have a fix for the first issue. For this one the issue seems to be that
we do have vec_cmp for _2 > { 0, 3, 2, 200 } when doing instruction
selection for
mask__11.18_97 = VEC_COND_EXPR ;
note the value is of vector boolean type. But we fail to have
vcond_maskV4BIV4BI.
ISTR we have fixed sth similar
by adding missing patterns with VnBImode result? But maybe forgot about
VLS modes here?
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #15 from JuzheZhong ---
Also, I find this following case that ARM SVE failed to optimize:
https://godbolt.org/z/d6YnneETj
#define N 16
typedef int half_word;
int foo2 ()
{
int i;
half_word ia[N];
half_word ic[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
half_word ib[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
/* Not worthwhile, only 2 parts per int */
for (i = 0; i < N; i++)
{
ia[i] = ib[i] + ic[i];
}
/* check results: */
for (i = 0; i < N; i++)
{
if (ia[i] != ib[i] + ic[i])
abort ();
}
return 0;
}
I guess your approach can fix that for ARM SVE. Maybe ARM SVE can also add
this case too.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #14 from JuzheZhong ---
Also this case ICE:
typedef unsigned char __attribute__((vector_size(4))) uvec;
int main (int argc, char *argv[]) {
int i;
int x = 0;
uvec uc0 = (uvec) {argc, 1, 2, 10};
unsigned char uc1[4] = {0, 3, 2, 200};
signed char ucg[4] = {1, 0, 0, 0 };
signed char ucl[4] = {0, 1, 0, 1 };
#define uc0_ ((unsigned char *))
for (i = 0; i < 4; i ++) {
x |= ucg[i] != (uc0_[i] > uc1[i]);
x |= ucl[i] != (uc0_[i] < uc1[i]);
}
return x;
}
during GIMPLE pass: isel
dump file: auto.c.256t.isel
auto.c: In function 'main':
auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:328
3 | int main (int argc, char *argv[]) {
| ^~~~
0x1bb55bd gimple_expand_vec_cond_expr
../../../../gcc/gcc/gimple-isel.cc:325
0x1bb57c6 execute
../../../../gcc/gcc/gimple-isel.cc:390
Looks odd, it ICE at gimple-isel.cc:
gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #13 from JuzheZhong ---
Thanks, Richi.
It does fix this issue.
This patch seems to cause an ICE in RISC-V:
#include
#include
#define N 128
int
main ()
{
uint8_t mask[N]
= {0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1};
uint8_t out[N] = {0};
for (uint8_t i = 0; i < N; ++i)
if (mask[i])
out[i] = i;
for (uint8_t i = 0; i < N; ++i)
{
if (mask[i])
assert (out[i] == i);
else
assert (out[i] == 0);
}
}
riscv64-unknown-elf-gcc --param riscv-autovec-preference=fixed-vlmax --param
riscv-autovec-lmul=m8 -O3 -S auto.c
during GIMPLE pass: fre
auto.c: In function 'main':
auto.c:7:1: internal compiler error: in execute_todo, at passes.cc:2137
7 | main ()
| ^~~~
0x1714290 execute_todo
../../../../gcc/gcc/passes.cc:2137
I guess this is caused by this following IR:
mask =
"\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01";
out = "\x00";
_51 = VIEW_CONVERT_EXPR("\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01");
mask__27.12_47 = _51 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0 };
.MASK_LEN_STORE (, 8B, mask__27.12_47, 128, 0, { 0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67,
68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87,
88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105,
106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121,
122, 123, 124, 125, 126, 127 });
There is a VIEW_CONVERT_EXPR here.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Should be fixed. Feel free to add a RISC-V specific testcase so we don't regress.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7c76c876e917a1f20a788f602cc78fff7d0a2a65 commit r14-4527-g7c76c876e917a1f20a788f602cc78fff7d0a2a65 Author: Richard Biener Date: Tue Oct 10 11:09:16 2023 +0200 Fix missed CSE with a BLKmode entity The following fixes fallout of r10-7145-g1dc00a8ec9aeba which made us cautionous about CSEing a load to an object that has padding bits. The added check also triggers for BLKmode entities like STRING_CSTs but by definition a BLKmode entity does not have padding bits. PR tree-optimization/111751 * tree-ssa-sccvn.cc (visit_reference_op_load): Exempt BLKmode result from the padding bits check.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #10 from rguenther at suse dot de ---
On Tue, 10 Oct 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
>
> --- Comment #9 from JuzheZhong ---
> (In reply to Richard Biener from comment #8)
> > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > vect__1.7_10 = MEM [(char *)];
> > vect__2.10_34 = MEM [(char *)];
> >
> > so these. The lookup result is a STRING_CST object. I'm testing a patch.
>
> I have compare and debug between ARM SVE and RVV.
> It seems that ARM SVE produce result of visit_reference_op_load is
> CONST_VECTOR:
>
> (gdb) p debug(to)
> { 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45 }
> (gdb) p to->typed.type->type_common.mode
> $23 = E_V16QImode
>
> However, RVV produce result of visit_reference_op_load is STRING_CST:
>
> (gdb) p debug (result)
> "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
>
> This is the BLKmode.
>
> Could you tell me where I should fix in RISC-V backend?
> It seems that it is not middle-end issue.
The IL into the SVE case is likely different. The difference is
wheher we have a direct hashtable hit for the load or whether we
need to go through vn_reference_lookup_3 which will perform the
type punning on its own.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #9 from JuzheZhong ---
(In reply to Richard Biener from comment #8)
> ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> vect__1.7_10 = MEM [(char *)];
> vect__2.10_34 = MEM [(char *)];
>
> so these. The lookup result is a STRING_CST object. I'm testing a patch.
I have compare and debug between ARM SVE and RVV.
It seems that ARM SVE produce result of visit_reference_op_load is
CONST_VECTOR:
(gdb) p debug(to)
{ 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45 }
(gdb) p to->typed.type->type_common.mode
$23 = E_V16QImode
However, RVV produce result of visit_reference_op_load is STRING_CST:
(gdb) p debug (result)
"\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
This is the BLKmode.
Could you tell me where I should fix in RISC-V backend?
It seems that it is not middle-end issue.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org CC||rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Richard Biener --- ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"; ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"; vect__1.7_10 = MEM [(char *)]; vect__2.10_34 = MEM [(char *)]; so these. The lookup result is a STRING_CST object. I'm testing a patch.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #7 from JuzheZhong ---
(In reply to Andrew Pinski from comment #6)
> (In reply to JuzheZhong from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> > >
> > > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > > vect__1.7_9 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > > 0,
> > > ... });
> > > vect__2.10_35 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1,
> > > -1,
> > > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > > 0,
> > > ... });
> >
> > I don't ARM SVE has issues ...
>
> It does as I mentioned if you use -fno-vect-cost-model, you get the above
> issue which should be optimized really to a constant vector ...
After investigation:
I found it failed to recognize its CONST_VECTOR value in FRE
/* Visit a load from a reference operator RHS, part of STMT, value number it,
and return true if the value number of the LHS has changed as a result. */
static bool
visit_reference_op_load (tree lhs, tree op, gimple *stmt)
{
bool changed = false;
tree result;
vn_reference_t res;
tree vuse = gimple_vuse (stmt);
tree last_vuse = vuse;
result = vn_reference_lookup (op, vuse, default_vn_walk_kind, , true,
_vuse);
/* We handle type-punning through unions by value-numbering based
on offset and size of the access. Be prepared to handle a
type-mismatch here via creating a VIEW_CONVERT_EXPR. */
if (result
&& !useless_type_conversion_p (TREE_TYPE (result), TREE_TYPE (op)))
{
/* Avoid the type punning in case the result mode has padding where
the op we lookup has not. */
if (maybe_lt (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (result))),
GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (op)
result = NULL_TREE;
The result is BLKmode, op is V16QImode
Then reach
/* Avoid the type punning in case the result mode has padding where
the op we lookup has not. */
if (maybe_lt (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (result))),
GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (op)
result = NULL_TREE;
If I delete this code, RVV can optimize it.
Do you have any suggestion ?
This is my observation:
Breakpoint 6, visit_reference_op_load (lhs=0x768364c8, op=0x76874410,
stmt=0x76872640) at ../../../../gcc/gcc/tree-ssa-sccvn.cc:5740
5740 result = vn_reference_lookup (op, vuse, default_vn_walk_kind, ,
true, _vuse);
(gdb) c
Continuing.
Breakpoint 6, visit_reference_op_load (lhs=0x768364c8, op=0x76874410,
stmt=0x76872640) at ../../../../gcc/gcc/tree-ssa-sccvn.cc:5740
5740 result = vn_reference_lookup (op, vuse, default_vn_walk_kind, ,
true, _vuse);
(gdb) n
5746 && !useless_type_conversion_p (TREE_TYPE (result), TREE_TYPE
(op)))
(gdb) p debug (result)
"\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
$9 = void
(gdb) p op->typed.type->type_common.mode
$10 = E_V16QImode
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #6 from Andrew Pinski ---
(In reply to JuzheZhong from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> >
> > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > vect__1.7_9 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > ... });
> > vect__2.10_35 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > ... });
>
> I don't ARM SVE has issues ...
It does as I mentioned if you use -fno-vect-cost-model, you get the above issue
which should be optimized really to a constant vector ...
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #5 from JuzheZhong ---
(In reply to Andrew Pinski from comment #4)
> The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
>
> ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> vect__1.7_9 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> ... });
> vect__2.10_35 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> ... });
I don't ARM SVE has issues ...
If we can choose fixed length vector mode to vectorize it, it will be well
optimized.
I think this is RISC-V target dependent issue.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #4 from Andrew Pinski ---
The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
vect__1.7_9 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... });
vect__2.10_35 = .MASK_LOAD (, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ...
});
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #3 from Andrew Pinski --- If you add `-fno-vect-cost-model` to aarch64 compiling, then it uses SVE and does not optimize to just `return 0`.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-10 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #1 from Andrew Pinski --- AARCH64 did vectorize the code just using non-SVE which then allowed to be optimized too.
