[Bug target/111317] RISC-V: Incorrect COST model for RVV conversions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111317 --- Comment #1 from Robin Dapp --- I think the default cost model is not too bad for these simple cases. Our emitted instructions match gimple pretty well. The thing we don't model is vsetvl. We could ignore it under the assumption that it

[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #12 from Robin Dapp --- Yes, as far as I know. I would also go ahead and merge the test suite patch now as there is already a v2 fix posted. Even if it's not the correct one it will be done soon so we should not let that block

[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #10 from Robin Dapp --- I would be OK with the riscv implementation, then we don't need to touch isel. Maybe a future vector extension will also help us here so we could just switch the implementation then.

[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 --- Comment #8 from Robin Dapp --- Yes, I doubt we would get much below 4 instructions with riscv specifics. A quick grep yesterday didn't reveal any aarch64 or gcn patterns for those (as long as they are not hidden behind some pattern

[Bug c/111337] ICE in gimple-isel.cc for RISC-V port

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

[Bug target/111311] New: RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311 Bug ID: 111311 Summary: RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug target/110559] Bad mask_load/mask_store codegen of RVV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110559 --- Comment #3 from Robin Dapp --- I got back to this again today, now that pressure-aware scheduling is the default. As mentioned before, it helps but doesn't get rid of the spills. Testing with the "generic ooo" scheduling model it looks

[Bug c/111153] RISC-V: Incorrect Vector cost model for reduction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53 --- Comment #1 from Robin Dapp --- We seem to decide that a slightly more expensive loop (one instruction more) without an epilogue is better than a loop with an epilogue. This looks intentional in the vectorizer cost estimation and is not

[Bug tree-optimization/111136] ICE in RISC-V test case since r14-3441-ga1558e9ad85693

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36 --- Comment #4 from Robin Dapp --- All gather-scatter tests pass for me again (the given example in particular) after applying this.

[Bug target/108271] Missed RVV cost model

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

[Bug tree-optimization/111136] New: ICE in RISC-V test case since r14-3441-ga1558e9ad85693

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36 Bug ID: 36 Summary: ICE in RISC-V test case since r14-3441-ga1558e9ad85693 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug rtl-optimization/108412] RISC-V: Negative optimization of GCSE && LOOP INVARIANTS

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

[Bug target/110559] Bad mask_load/mask_store codegen of RVV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110559 --- Comment #1 from Robin Dapp --- This can be improved in parts by enabling register-pressure aware scheduling. The rest is due to the default issue rate of 1. Setting proper instruction latency will then obviously cause a bit more reordering

[Bug tree-optimization/100756] [12 Regression] vect: Superfluous epilog created on s390x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756 --- Comment #8 from rdapp at gcc dot gnu.org --- For completeness: haven't observed any fallout on s390 since and the regression is fixed.

[Bug middle-end/107617] SCC-VN with len_store and big endian

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617 --- Comment #1 from rdapp at gcc dot gnu.org --- For completeness, the mailing list thread is here: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602252.html

[Bug middle-end/107617] SCC-VN with len_store and big endian

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617 rdapp at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4

[Bug middle-end/107617] New: SCC-VN with len_store and big endian

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617 Bug ID: 107617 Summary: SCC-VN with len_store and big endian Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end

[Bug tree-optimization/100756] vect: Superfluous epilog created on s390x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756 rdapp at gcc dot gnu.org changed: What|Removed |Added CC||rdapp at gcc dot gnu.org ---

[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu since r13-2251-g1930c5d05ceff2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919 --- Comment #8 from rdapp at gcc dot gnu.org --- Yes, one of dst and dest is superflous. Looks good like that. I bootstrapped the same patch locally already, no regressions.

[Bug middle-end/91213] Missed optimization: (sub X Y) -> (xor X Y) when Y <= X and isPowerOf2(X + 1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91213 --- Comment #9 from rdapp at gcc dot gnu.org --- The regressions are unrelated and due to another patch that I still had on the same branch.

[Bug middle-end/91213] Missed optimization: (sub X Y) -> (xor X Y) when Y <= X and isPowerOf2(X + 1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91213 --- Comment #8 from rdapp at gcc dot gnu.org --- Hacked something together, inspired by the other cases that try two different sequences. Does this go into the right direction? Works for me on s390. I see some regressions related to predictive

[Bug middle-end/91213] Missed optimization: (sub X Y) -> (xor X Y) when Y <= X and isPowerOf2(X + 1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91213 rdapp at gcc dot gnu.org changed: What|Removed |Added CC||rdapp at gcc dot gnu.org ---

[Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701 --- Comment #3 from rdapp at gcc dot gnu.org --- I though expand (or combine) were independent of value range. What would be the proper place for it then?

[Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701 rdapp at gcc dot gnu.org changed: What|Removed |Added Target|s390|s390 x86_64-linux-gnu

[Bug rtl-optimization/105988] [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 since r6-4873-gebedc9a3414d8422

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105988 rdapp at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu s390 ---

[Bug middle-end/106527] New: ICE with modulo scheduling dump (-fdump-rtl-sms)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106527 Bug ID: 106527 Summary: ICE with modulo scheduling dump (-fdump-rtl-sms) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3

<    1   2   3