[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #10 from Robin Dapp --- Yes it helps. Great that get_gimple_for_ssa_name is right below get_rtx_for_ssa_name that I stepped through several times while debugging and I didn't realize the connection, g. But thanks! Good thing

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #9 from Richard Biener --- (In reply to Robin Dapp from comment #8) > Created attachment 58037 [details] > Expand dump > > Dump attached. Insn 209 is the problematic one. > The changing from _911 to 1078 happens in

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #8 from Robin Dapp --- Created attachment 58037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58037=edit Expand dump Dump attached. Insn 209 is the problematic one. The changing from _911 to 1078 happens in

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #7 from Richard Biener --- (In reply to Robin Dapp from comment #6) > This one is really a bit tricky. > > We have the following situation: > > loop: > > # vectp_g.178_1078 = PHI > _911 = vectp_g.178_1078 > MASK_LEN_LOAD

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 Robin Dapp changed: What|Removed |Added CC||rguenth at gcc dot gnu.org,

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #5 from Robin Dapp --- What happens is that code sinking does: Sinking # VUSE <.MEM_1235> vect__173.251_1238 = .MASK_LEN_LOAD (_911, 32B, { -1, -1, -1, -1 }, loop_len_1064, 0); from bb 3 to bb 4 so we have vect__173.251_1238 =

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #4 from Robin Dapp --- Ok, it looks like we do 5 iterations with the last one being length-masked to length 2 and then in the "live extraction" phase use "iteration 6".

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #3 from Robin Dapp --- > probably -fwhole-program is enough, -flto not needed(?) Yes, -fwhole-program is sufficient. > > # vectp_g.248_1401 = PHI > ... > _1411 = .SELECT_VL (ivtmp_1409, POLY_INT_CST [2, 2]); > .. >

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #2 from Richard Biener --- probably -fwhole-program is enough, -flto not needed(?) # vectp_g.248_1401 = PHI ... _1411 = .SELECT_VL (ivtmp_1409, POLY_INT_CST [2, 2]); .. vect__193.250_1403 = .MASK_LEN_LOAD (vectp_g.248_1401,

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Ever confirmed|0

[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #1 from Robin Dapp --- Confirmed.