https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #23 from Robin Dapp ---
> this is:
>
> _429 = mask_patt_205.47_276[i] ? vect_cst__262[i] : (vect_cst__262 <<
> {0,..})[i];
> vect_iftmp.55_287 = mask_patt_209.54_286[i] ? _429 [i] : vect_cst__262[i]
But isn't it rather
_429 = mask_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #22 from Andrew Pinski ---
(In reply to Robin Dapp from comment #19)
> What seems odd to me is that in fre5 we simplify
>
> _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
> ... });
> vect_prephitmp_12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #21 from Andrew Pinski ---
(In reply to JuzheZhong from comment #20)
> Does ARM SVE have the same issue too ? Since I think we should be using same
> folding optimization as ARM SVE.
I could not reproduce it with SVE, see comment 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #20 from JuzheZhong ---
(In reply to Robin Dapp from comment #19)
> What seems odd to me is that in fre5 we simplify
>
> _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
> ... });
> vect_prephitmp_129.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #19 from Robin Dapp ---
What seems odd to me is that in fre5 we simplify
_429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
... });
vect_prephitmp_129.51_282 = _429;
vect_iftmp.55_287 = VEC_COND_EXPR ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #18 from Robin Dapp ---
Hehe no it doesn't make sense... I wrongly read a v2 as a v1. Please
disregard the last message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #17 from Robin Dapp ---
Grasping for straws by blaming qemu ;)
At some point we do the vector shift
vsll.vv v1,v2,v2,v0.t
but the mask v0 is all zeros:
gdb:
b = {0 }
According to the mask-undisturbed policy set before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #16 from Robin Dapp ---
Disabling vec_extract makes us operate on non-partial vectors, though so there
are a lot of differences in codegen. I'm going to have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #15 from JuzheZhong ---
Hi, Robin.
I tried to disable vec_extract, then the case passed.
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 3b32369f68c..b61b886ef3d 100644
--- a/gcc/config/riscv/autovec.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #14 from Andrew Pinski ---
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc
-static t.c -O3 -fno-vect-cost-model -march=armv9-a+sve
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #13 from JuzheZhong ---
Ok. I found a regression between rvv-next and trunk.
I believe it is GCC-12 vs GCC-14:
rvv-next:
...
.L11:
li t1,31
mv a2,a1
bleua7,t1,.L12
bne a6,zero,.L13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #12 from Andrew Pinski ---
Let test tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #11 from JuzheZhong ---
(In reply to Robin Dapp from comment #10)
> The compile farm machine I'm using doesn't have SVE.
> Compiling with -march=armv8-a -O3 pr113607.c -fno-vect-cost-model and
> running it returns 0 (i.e. ok).
>
> p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #10 from Robin Dapp ---
The compile farm machine I'm using doesn't have SVE.
Compiling with -march=armv8-a -O3 pr113607.c -fno-vect-cost-model and running
it returns 0 (i.e. ok).
pr113607.c:35:5: note: vectorized 3 loops in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #9 from JuzheZhong ---
Hi, Robin.
Could you try this case on latest ARM SVE ?
with -march=armv8-a+sve -O3 -fno-vect-cost-model.
I want to make sure first it is not an middle-end bug.
The RVV vectorized IR is same as ARM SVE.
Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #8 from JuzheZhong ---
Ok. I can reproduce it too.
I am gonna work on fixing it.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #7 from Robin Dapp ---
Yep, that one fails for me now, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #6 from Patrick O'Neill ---
I think I may have messed up when copy/pasting the testcase. Please try this
testcase:
struct {
signed b;
} c, d = {6};
short e, f;
int g[1000];
signed char h;
int i, j;
long k, l;
long m(long n, long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #5 from Patrick O'Neill ---
Hmm that's odd. I just reproduced with tip-of-tree GCC.
> /scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -O3 -march=rv64gcv red.c -o user-config-o3.out
> QEMU_C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #4 from Robin Dapp ---
I cannot reproduce it either, tried with -ftree-vectorize as well as
-fno-vect-cost-model.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #3 from JuzheZhong ---
I tried trunk GCC to run your case with SPIKE, still didn't reproduce this
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #2 from JuzheZhong ---
I can't reproduce this issue.
Could you test it with this patch applied ?
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643934.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #1 from JuzheZhong ---
I can reproduce this issue.
Could you test it with this patch applied ?
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643934.html
23 matches
Mail list logo
