[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #17 from GCC Commits --- The releases/gcc-14 branch has been updated by Kito Cheng : https://gcc.gnu.org/g:2d7dda84730e0e364b3b1776d387c9ceb85385ea commit r14-10464-g2d7dda84730e0e364b3b1776d387c9ceb85385ea Author: Robin Dapp Date

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 Robin Dapp changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #15 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:acc3b703c05debc6276451f9daae5d0ffc797eac commit r15-1861-gacc3b703c05debc6276451f9daae5d0ffc797eac Author: Robin Dapp Date: Mon Ju

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #14 from Robin Dapp --- Thanks Kito. In addition, I asked Daniel to have a look into the vmv.s.x policy handling. From what I saw it is special in that it currently always uses undisturbed and doesn't observe the specified policy.

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #13 from Kito Cheng --- FYI: PR for riscv-gnu-toolchain: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1501

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #12 from Kito Cheng --- Qemu has provide two option to fill up all-one to agnostic policy: rvv_ta_all_1s and rvv_ma_all_1s*, I guess we could enable that by default in riscv-gnu-toolchain to discover more potential bugs. * qemu-r

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #11 from Robin Dapp --- > I believe it is VSETVL PASS doing the fusion, fuse all "vsetvl" according > their > demand field into a single "vsetvli" and put them since beginning. Yes, and the vsetvl fusion is very useful here.

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #10 from JuzheZhong --- (In reply to Robin Dapp from comment #9) > We already merge with operand[0], just the TU is missing as far as I can > tell. > > I'm seeing the following output with my patch: > > vsetivlizero,8

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #9 from Robin Dapp --- We already merge with operand[0], just the TU is missing as far as I can tell. I'm seeing the following output with my patch: vsetivlizero,8,e16,mf4,tu,ma vle16.v v1,0(a1) vmv.

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #8 from JuzheZhong --- I think we should include operands[0] as the "merge/maskoff" operand which we need to depend on and use TU for vec_set pattern Take ARM for example: (define_expand "vec_set" [(match_operand:VALL_F16 0 "regi

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #7 from Robin Dapp --- I checked. It looks like qemu indeed always implicitly uses TU for vmv.s.x regardless of the actual setting. This behavior masks the bug here.

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #6 from Li Pan --- (In reply to Robin Dapp from comment #5) > > zvl128b => GOOD. > > vec_set_vnx8hi_0: > > vl1re16.v v1,0(a1) > > vsetivlizero,1,e16,m1,ta,ma > > vmv.s.x v1,a2 > > vs1r.v

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #5 from Robin Dapp --- > zvl128b => GOOD. > vec_set_vnx8hi_0: > vl1re16.v v1,0(a1) > vsetivlizero,1,e16,m1,ta,ma > vmv.s.x v1,a2 > vs1r.v v1,0(a0) // Only store 1 element as source code

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #4 from Robin Dapp --- Sorry, just got back from the RISC-V summit. IMHO, yes, it should be TU. We have the same thing for the not-element-0 case. I wonder why it doesn't fail with spike or qemu. Probably qemu doesn't do anything

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #3 from Li Pan --- Both qemu and spike cannot reproduce the failure as mentioned "hecking (res[1] != 1) will get abort()". But I bet you mean that we have an additional and unnecessary store here, right? zvl128b => GOOD. vec_set_v

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #2 from Kito Cheng --- TU may not help for this case since we can't guarantee it's use v1 outside, I mean the argument is passed via a1 (pointer) rather than passed via v1.

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #1 from JuzheZhong --- It seems that we should use TU instead of TA? Robin ?