[Bug target/118832] RISC-V: internal compiler error: could not split insn, with V+Zbb enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832 --- Comment #3 from Robin Dapp --- The mechanism that introduces those unsplit instructions always seems to be via reload. At some point we see a REG_EQUAL note with a const_vector. As we, generally, can rematerialize constants we try to do th

[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #9 from Robin Dapp --- Bisecting further only leads to the commit that introduced the vector ABI. Comparing the dumps with and without vector ABI is very tedious because a lot of things differ. It looks like we cannot create a relo

[Bug target/117722] RISC-V: Failed to vectorize x264_pixel_sad_4x4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722 --- Comment #18 from Robin Dapp --- > But the point here really here is we don't need the widening semantics, more > twice. The min+max+sub in loops with a final reducing sum should do the > trick. OK I guess it can be argued that minus (max

[Bug target/117722] RISC-V: Failed to vectorize x264_pixel_sad_4x4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722 --- Comment #15 from Robin Dapp --- (In reply to Vineet Gupta from comment #14) > (In reply to Li Pan from comment #7) > > Created attachment 59661 [details] > > with usad pattern > > Can you please post the patch, lest we duplicate your effort

[Bug target/117990] [15 regression] RISC-V: Miscompile at -O3 zvl 256 since r15-4746-g30435cc2610

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990 --- Comment #7 from Robin Dapp --- Does it work when we use the old gather-load code path instead of the strided load or does this have the same problem?

[Bug target/118019] RISC-V: Performance regression in hottest function of X264

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019 --- Comment #12 from Robin Dapp --- Could you please check if the patch helped?

[Bug target/117383] gcc relies on RISC-V vcompress instruction undefined behaviour

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

[Bug target/118057] RISC-V: Can't vectorize load and store with zvl128b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118057 --- Comment #2 from Robin Dapp --- I think depending on the performance of strided loads/stores this can be profitable to vectorize. Looks like we need loop versioning to account for the possible aliasing but once this is out of the way we coul

[Bug target/117682] [15 Regression] rv64gcv_zvl256b miscompile since r15-3228-g771256bcb9d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117682 --- Comment #3 from Robin Dapp --- The issue is in the way we construct an interleaved VLA const pattern. For efficiency we try to use a larger element width, here 16 bits, to initialize two values in one. I believe this doesn't go along well

[Bug target/118057] RISC-V: Can't vectorize load and store with zvl128b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118057 --- Comment #6 from Robin Dapp --- (In reply to Richard Biener from comment #5) > I would expect this to be always slower when vectorized unless the core is > seriously bottle-necked on the frontend. The loads/stores need to be > decomposed to

[Bug target/116242] [meta-bug] Tracker for zvl issues in RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242 Bug 116242 depends on bug 115995, which changed state. Bug 115995 Summary: RISC-V: Can't generate portable RVV code for rv64gcv_zvl512b https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115995 What|Removed |Added --

[Bug target/115995] RISC-V: Can't generate portable RVV code for rv64gcv_zvl512b

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

[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #15 from Robin Dapp --- > Based on earlier builds this file will take 2.5 to 3 hours to build (while > all other cores are idle). insn-attrtab.c doesn't consist of many functions so a split won't help. Given that we have a number o

[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #12 from Robin Dapp --- It looks like the insn-recog split didn't help here but maybe of of the mentioned commits slowed down the compilation of insn-attrtab.c? Has anybody made progress with narrowing down the problem?

[Bug bootstrap/116146] Split insn-recog.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116146 Robin Dapp changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug rtl-optimization/111619] 'make profiledbootstrap' makes 10+ minutes on insn-recog.cc (x86_64-linux)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #14 f

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Bug 84402 depends on bug 116146, which changed state. Bug 116146 Summary: Split insn-recog.cc https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116146 What|Removed |Added -

[Bug tree-optimization/116166] [13 Regression] risc-v (last) insn-emit-nn.c build takes hours

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #32 f

[Bug target/117878] RISC-V: ICE when build spec17 526.blender_r with -O3 -march=rv64gcv_zvl256b

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

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 117878, which changed state. Bug 117878 Summary: RISC-V: ICE when build spec17 526.blender_r with -O3 -march=rv64gcv_zvl256b https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117878 What|Removed

[Bug target/117353] [15 regression] RISC-V: ICE when building libcrypt since r15-3228-g771256bcb9ddc4

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

[Bug target/117990] [15 regression] RISC-V: Miscompile at -O3 zvl 256 since r15-4746-g30435cc2610

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990 Robin Dapp changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug target/117878] RISC-V: ICE when build spec17 526.blender_r with -O3 -march=rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117878 --- Comment #11 from Robin Dapp --- I'm not really sure. For now I hope not. If we hit similar problems again that are not easily fixable we can reconsider.

[Bug target/118019] RISC-V: Performance regression in hottest function of X264

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019 --- Comment #9 from Robin Dapp --- I think I'll post a patch to increase vec_construct costs first. It's just too cheap right now. That should already help with the default settings.

[Bug target/118019] RISC-V: Performance regression in hottest function of X264

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019 --- Comment #5 from Robin Dapp --- According to Li Pan's results this is "just" vector strict align again? We should be vectorizing the first loop, in particular after the SLP-grouping changes. I realize it's annoying having to resort to strict

[Bug target/118019] RISC-V: Performance regression in hottest function of X264

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019 --- Comment #7 from Robin Dapp --- > The problem is GCC-15 has performance regression compare to GCC-14 on both > strict align and we should fix it, we can't specify use no strict align in > GCC-15 to pretend that we don't have such performance

[Bug target/118036] [15 Regression] RISC-V: gcc.dg/vect/vect-alias-check-1[12].c abort

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118036 Robin Dapp changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at

[Bug target/118019] RISC-V: Performance regression in hottest function of X264

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019 --- Comment #10 from Robin Dapp --- Ah I see - the actual vector code isn't even that bad and the vec_constructs aren't either. The problem is rather that we have slow unaligned (scalar) access with the default tune model. Thus we need to load

[Bug target/118140] [14/15 Regression] RISC-V: Miscompile with -march=rv64gcv_zvl256b -O3 since r14-5076-g01c18f58d37

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140 --- Comment #8 from Robin Dapp --- The optimized tree looks good apart from 'd' and the return value :) [local count: 76665171]: e_lsm.8_12 = e; _55 = .MASK_LEN_LOAD (&MEM <_Bool[17]> [(void *)&f + 4B], 8B, { -1, ... }, _54(D), 13, 0);

[Bug target/117722] RISC-V: Failed to vectorize x264_pixel_sad_4x4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722 --- Comment #11 from Robin Dapp --- (In reply to Li Pan from comment #9) > Created attachment 59663 [details] > before_vs_after when outer loop is 128 Ok, that's a different loop then. I'm seeing vmv1rs in the current version, is that what you

[Bug target/117722] RISC-V: Failed to vectorize x264_pixel_sad_4x4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722 --- Comment #8 from Robin Dapp --- So the difference is (usad expansion) vmax vmin vsub vsext vadd vs (right now) vwsub vneg vmax vwadd Why is that preferable?

[Bug target/118182] RISC-V: Miscompile for 410.bwaves, 416.gamess and 465.tonto from spec2006

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118182 --- Comment #1 from Robin Dapp --- We should probably always populate the initial value as the VL=0 only refers (should refer) to the actual reduction?

[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #10 from Robin Dapp --- It's also odd to see single-register spills for an LMUL8 register group, that doesn't seem right. (insn 174 169 180 2 (set (reg:RVVM1SF 247) (reg:RVVM1SF 112 v16)) "pr115458.c":48:33 2749 {*movrvvm1sf

[Bug tree-optimization/118140] [14/15 Regression] ifcvt miscompiles program at -O3 since r14-5076-g01c18f58d37 for riscv and aarch64 (with SVE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140 --- Comment #18 from Robin Dapp --- Fixed on trunk. Guess we still need a backport.

[Bug target/118154] [15 Regression] RISC-V: Miscompile with -march=rv64gcv -O3 since r15-5117-g0b27a7dd050

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118154 Robin Dapp changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug tree-optimization/118140] [14/15 Regression] ifcvt miscompiles program at -O3 since r14-5076-g01c18f58d37 for riscv and aarch64 (with SVE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140 Robin Dapp changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug target/118019] RISC-V: Performance regression in hottest function of X264

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019 --- Comment #15 from Robin Dapp --- I think it's r15-2820-gab18785840d7b8.

[Bug target/118154] [15 Regression] RISC-V: Miscompile with -march=rv64gcv -O3 since r15-5117-g0b27a7dd050

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118154 Robin Dapp changed: What|Removed |Added Component|tree-optimization |target --- Comment #6 from Robin Dapp ---

[Bug tree-optimization/115340] Loop/SLP vectorization possible inefficiency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115340 --- Comment #2 from Robin Dapp --- > The stores are not considered "grouped" because they have gaps. > To do better we'd have to improve the store dataref analysis to see > that a vectorization factor of four would "close" the gaps, or more > g

[Bug tree-optimization/118154] [15 Regression] RISC-V: Miscompile with -march=rv64gcv -O3 since r15-5117-g0b27a7dd050

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118154 --- Comment #5 from Robin Dapp --- Confirmed, funnily only happens with a QEMU VLEN=128 and not with VLEN >= 256. -fwrapv and -fno-strict-aliasing are not necessary for me. Another "funny" thing: vect__5.15_44 = .COND_LEN_MAX ({ -1, ... },

[Bug tree-optimization/118154] [15 Regression] RISC-V: Miscompile with -march=rv64gcv -O3 since r15-5117-g0b27a7dd050

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118154 --- Comment #3 from Robin Dapp --- Uh, what a nice small test case ;) I'll have a look when I'm back mid next week.

[Bug target/118832] RISC-V: internal compiler error: could not split insn, with V+Zbb enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832 --- Comment #8 from Robin Dapp --- I think for vec_duplicate the idea is the same as for all the other splits - keep it in simple shape so we can combine/fwprop etc. It also helps converting e.g. vmv.v.x v3,a3 vadd.vv v1, v2, v3 into vad

[Bug target/118832] RISC-V: internal compiler error: could not split insn, with V+Zbb enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832 --- Comment #6 from Robin Dapp --- Thanks for laying it out so clearly. Helps to put things into perspective. I believe all our insn_and_split patterns already have can_create_pseudo_p in their condition so shouldn't match after reload. Warra

[Bug tree-optimization/116351] RISC-V ICE: in get_len_load_store_mode, at optabs-tree.cc:664

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116351 --- Comment #3 from Robin Dapp --- I started with a fix here: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671939.html but, due to other priorities, dropped the ball :/ Feel free to pick up from there.

[Bug target/118950] [14/15 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 Robin Dapp changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6

[Bug target/116686] [15 Regression] RISC-V: gcc.target/riscv/rvv/autovec/pr114734.c failing with zvl1024b lmul2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #7 fr

[Bug target/114516] RISC-V: TSVC2 s315 has spill with dynamic lmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516 --- Comment #1 from Robin Dapp --- The issue is that we're not considering pattern statements for costing. It's rather straightforward to include those as well which would fix this PR. I'm going to test a patch locally.

[Bug target/118950] [14/15 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 --- Comment #5 from Robin Dapp --- Yeah, the original statement is recognized as a mask conversion pattern: pr118950.c:9:21: note: vect_recog_mask_conversion_pattern: detected: _152 = .MASK_LOAD (_230, 8B, _229, 0); pr118950.c:9:21: note: m

[Bug tree-optimization/118950] [14 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 --- Comment #11 from Robin Dapp --- I figured this particular problem on RISC-V won't be fixed on GCC 14 because we don't have the zeroing of masked elements there. But you're referring to backporting just this patch, right?

[Bug target/118595] [15 regression] RISC-V: gfortran/c-interop test execution failures on RVV zvl > 128b since r15-3228-g771256bcb9d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118595 --- Comment #2 from Robin Dapp --- Hmm I'm not seeing those locally with -march=rv64gcv_zvl256b at least. Which exact options were used to run the test suite? Or have those fails disappeared in the meanwhile?

[Bug target/114516] RISC-V: TSVC2 s315 has spill with dynamic lmul

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

[Bug tree-optimization/116773] [meta-bug] TSVC missed optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116773 Bug 116773 depends on bug 114516, which changed state. Bug 114516 Summary: RISC-V: TSVC2 s315 has spill with dynamic lmul https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516 What|Removed |Added

[Bug target/118950] [14/15 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be

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

[Bug target/118950] [14/15 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 --- Comment #4 from Robin Dapp --- It indeed appears is if we need zeroing of the loaded gather values but bool type_mode_padding_p = TYPE_PRECISION (scalar_type) < GET_MODE_PRECISION (GET_MODE_INNER (mode)); is false. The last of the

[Bug target/117955] GCC generate illegal riscv instruction `vsetvli zero,zero,e64,mf4,ta,ma` with -O2 and -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #7 fr

[Bug target/115703] [15 Regression] rv64gcv_zvl256b miscompile since r15-1579-g792f97b44ff

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

[Bug target/116242] [meta-bug] Tracker for zvl issues in RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242 Bug 116242 depends on bug 115703, which changed state. Bug 115703 Summary: [15 Regression] rv64gcv_zvl256b miscompile since r15-1579-g792f97b44ff https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115703 What|Removed

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114 --- Comment #9 from Robin Dapp --- I suspect the problem lies somewhere here: _11 = .VEC_EXTRACT (mask__83.22_110, 0); _23 = MEM[(short int *)&t + 20B]; _24 = _23 & _132; _25 = _24 != 0; _121 = () _25; _157 = _11 ^ _121; For _121

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114 --- Comment #17 from Robin Dapp --- > No you got it wrong. > _121 will either be -1 or 0. _11 should be -1 or 0 too. > So the question is what was the VEC_EXTRACT doing the right thing? Is it > 0/-1 or 0/1? I literally mentioned VEC_EXTRACT in

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114 --- Comment #4 from Robin Dapp --- Very weird indeed. It looks like we're not even vectorizing? I mean, sure, we use vector instructions but they are all broadcast from scalars? (VMAT_INVARIANT) And in the end we extract the first element wit

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114 --- Comment #10 from Robin Dapp --- The test passes with -fno-vrp, so maybe the optimized tree isn't correct after all? Folding statement: _157 = _26 ? -1 : 0; Matching expression match.pd:161, gimple-match-10.cc:33 Matching expression match.pd

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114 --- Comment #6 from Robin Dapp --- As convoluted (and redundant) as it looks but the optimized tree looks at least correct to me. Maybe a backend issue? But I don't see costing for what we emit in the vectorizer and I didn't yet find where we

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114 --- Comment #11 from Robin Dapp --- /* In GIMPLE, getting rid of 2 conversions for one new results in smaller IL. */ (simplify (convert (bitop:cs@2 (nop_convert:s @0) @1)) (if (GIMPLE && TREE_CODE (@1) != INTEGER_CST &&

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114 --- Comment #20 from Robin Dapp --- Hmm, so right now we return "1" or "0" when extracting from a mask, not "-1" or "0" and that's what aarch64/SVE does as well. We cannot start returning a sign-extended -1 all of a sudden. There is an inconsi

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114 --- Comment #22 from Robin Dapp --- > Is that not happening? What value does _164 actually end up being? > > In other words, if the XOR is happening in GPRs, it doesn't matter whether > the register holds 1 or -1 (or 3) for a true boolean. Th

[Bug target/119224] RISC-V: sad 16x16 spilling since r15-6673-gb755c151fde4ad

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224 --- Comment #2 from Robin Dapp --- I'm afraid that's due to scheduling (and not RA spilling). Of course there shouldn't be any vector stores in this loop and with -fno-schedule-insns there aren't any. It's much worse for zvl128b even. While t

[Bug target/119224] RISC-V: sad 16x16 spilling since r15-6673-gb755c151fde4ad

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224 --- Comment #4 from Robin Dapp --- Ah, sorry, I always specify -mno-vector-strict-align by default. It's always that option that allows us to unroll, otherwise unrolling will lead to misaligned accesses. And -mtune=generic-ooo defaults to -mno

[Bug target/119224] RISC-V: sad 16x16 spilling since r15-6673-gb755c151fde4ad

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224 --- Comment #7 from Robin Dapp --- > So this why you weren't seeing it but I'm confused about the rationale... > I unpack above to following statements > > 1. -mno-vector-strict-align allows us to unroll - seems ok. > 2. Otherwise (-mvector-str

[Bug rtl-optimization/119115] [15 regression] RISC-V: miscompile at -O3 with zvl256b -fsigned-char -fwrapv since r15-1579-g792f97b44ff

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115 --- Comment #5 from Robin Dapp --- The problematic vsetvl is vsetvli zero,a3,e16,m1,ta,ma which was a vsetvli a4,a3,e8,mf2,ta,ma vsetvli t1,a3,e8,mf2,ta,ma with the simple strategy.

[Bug target/119115] [15 regression] RISC-V: miscompile at -O3 with zvl256b -fsigned-char -fwrapv since r15-1579-g792f97b44ff

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115 --- Comment #2 from Robin Dapp --- (In reply to Andrew Pinski from comment #1) > Could this be another one of the vsetivli failures? 100% as I get "0" with --param=vsetvl-strategy=simple. But at first sight unrelated to the previous ones. Wil

[Bug target/119115] [15 regression] RISC-V: miscompile at -O3 with zvl256b -fsigned-char -fwrapv since r15-1579-g792f97b44ff

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115 Robin Dapp changed: What|Removed |Added Last reconfirmed||2025-3-4 --- Comment #3 from Robin Dapp -

[Bug rtl-optimization/119115] [15 regression] RISC-V: miscompile at -O3 with zvl256b -fsigned-char -fwrapv since r15-1579-g792f97b44ff

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

[Bug target/117955] GCC generate illegal riscv instruction `vsetvli zero,zero,e64,mf4,ta,ma` with -O2 and -O3

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

[Bug target/119361] RISC-V: x264 satd_4x4 stack spilling with mtune=generic-ooo for vls code but not on vla code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361 --- Comment #4 from Robin Dapp --- (In reply to Edwin Lu from comment #3) > I'm not familiar enough with how the two modes interact with each other but > I guess my question is, why do we have so many conversions between the two > modes? What's

[Bug target/119361] RISC-V: x264 satd_4x4 stack spilling with mtune=generic-ooo for vls code but not on vla code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361 --- Comment #2 from Robin Dapp --- I looked into this some more and it points to a general deficiency in how we handle the split between VLA and VLS modes. With ...bits=zvl the RVVM1SI etc modes. become VLS modes. In turn, this means that whene

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114 Robin Dapp changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug target/119361] RISC-V: x264 satd_4x4 stack spilling with mtune=generic-ooo for vls code but not on vla code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361 --- Comment #1 from Robin Dapp --- The issue is due to: _279 = BIT_FIELD_REF <_480, 64, 0>; _330 = BIT_FIELD_REF <_480, 64, 64>; _340 = BIT_FIELD_REF <_481, 64, 0>; _350 = BIT_FIELD_REF <_481, 64, 64>; Ideally they expand to simple sl

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119672 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #6 fr

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119672 --- Comment #8 from Robin Dapp --- (In reply to Jakub Jelinek from comment #7) > Thanks, I've posted it to gcc-patches in case some CI picks it up too: > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680408.html Testing looked good on rv

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547 --- Comment #5 from Robin Dapp --- Do you happen to have an excution test ready so I can have a look?

[Bug middle-end/119577] New: RISC-V: Redundant vector IV roundtrip.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577 Bug ID: 119577 Summary: RISC-V: Redundant vector IV roundtrip. Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement

[Bug target/119572] [15 Regression] Recent change triggers regression on RISC-V vector test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119572 Robin Dapp changed: What|Removed |Added Priority|P1 |P3 --- Comment #3 from Robin Dapp --- (In

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #17 f

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547 --- Comment #16 from Robin Dapp --- > Yes, it is precisely the issue I have encountered in cvtScale8s64f (actually > in cvt_64f). After the commit 34ae3a99, the default value of > LOGICAL_OP_NON_SHORT_CIRCUIT has changed from 0 into 1, it will c

[Bug c++/116595] default-initialization of vfloat32m1x4_t (RISCV V) or svfloat32x4_t (Armv9-a SVE) causes ICE

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

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547 --- Comment #15 from Robin Dapp --- > Yes, it is precisely the issue I have encountered in cvtScale8s64f (actually > in cvt_64f). After the commit 34ae3a99, the default value of > LOGICAL_OP_NON_SHORT_CIRCUIT has changed from 0 into 1, it will c

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547 --- Comment #12 from Robin Dapp --- > I recompile the opencv application with current gcc(commit b6aafe9a5b), and > it still reproduce this bug. Do you have apply the patch of step 3 which > enable vector implement of cvt_64f function? Yes, I

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547 --- Comment #13 from Robin Dapp --- Hmm, now I compiled with -O3 on top of --param logical-op-non-short-circuit=0 (which shouldn't actually be necessary or change anything as it's the default) but there is a segmentation fault in _ZN2cv12cpu_b

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547 --- Comment #9 from Robin Dapp --- > cmake --build cross-build/$BUILD_DIR-gcc --target opencv_test_core -j10 > ``` > 4. run > ``` > export LD_LIBRARY_PATH=//lib > ./opencv_test_core --gtest_filter="Core_ConvertScale/ElemWiseTest.accuracy/0"

[Bug c++/116595] default-initialization of vfloat32m1x4_t (RISCV V) or svfloat32x4_t (Armv9-a SVE) causes ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595 Robin Dapp changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug c++/116595] default-initialization of vfloat32m1x4_t (RISCV V) or svfloat32x4_t (Armv9-a SVE) causes ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595 --- Comment #7 from Robin Dapp --- Ah, not a regression but just a checking assert, sorry.

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547 --- Comment #10 from Robin Dapp --- > 4. run > ``` > export LD_LIBRARY_PATH=//lib > ./opencv_test_core --gtest_filter="Core_ConvertScale/ElemWiseTest.accuracy/0" > ``` [==] Running 1 test from 1 test case. [--] Global test e

[Bug target/119373] RISC-V: missed unrolling opportunity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119373 --- Comment #5 from Robin Dapp --- > The analysis of SPEC2017's 510.parest_r shows that the topmost basic block > is a tight loop (see attached reducer). Once vectorised, by unrolling and > mutualising 4 instructions, AArch64 achieves a 22% redu

[Bug target/119832] RISC-V: Redundant floating point rounding mode store/restore

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

[Bug target/120067] RISC-V: x264 sub4x4_dct high icount

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120067 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #4 fr

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

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

[Bug middle-end/119577] RISC-V: Redundant vector IV roundtrip.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577 --- Comment #3 from Robin Dapp --- I manage to have a quick look at the code now. It looks like we force live every induction and build slp instances for the IV increments. I don't think adjusting the actual IV creation in vectorizable_inducti

[Bug tree-optimization/118950] [14 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 --- Comment #13 from Robin Dapp --- Going to push this to the 14 branch later today if the x86 testsuite shows no regressions.

[Bug tree-optimization/118950] [14 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 Robin Dapp changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

<    1   2   3   4