[Bug target/98596] registers not reused on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596 Vineet Gupta changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||vineetg at gcc dot gnu.org --- Comment #3 from Vineet Gupta --- This is fixed with following commit (and will make it into gcc-14) commit b41d7eb0e14785ff0ad6e6922cbd4c880e680bf9 Author: Vineet Gupta Date: Mon Aug 7 13:45:29 2023 -0700 RISC-V: Enable Hoist to GCSE simple constants Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for hoist candidates. For a simple const (say 6 which needs seperate insn "LI 6") backend currently returns 0, causing Hoist to bail and elide GCSE. Note that constants requiring more than 1 insns to setup were working fine since riscv_rtx_costs () was returning non-zero (although that itself might need refining: see bugzilla 39). To keep testsuite parity, some V tests need updating which started failing in the new costing regime.
[Bug target/98596] registers not reused on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement CC||pinskia at gcc dot gnu.org
[Bug target/98596] registers not reused on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596 --- Comment #2 from Kito Cheng --- Few years ago, Monk and me has write a very detailed cost model for nds32 port, that way might able to fix the issue and further optimized for the code size and performance, but...it need lots time to fine tune and run benchmark again and again, so not sure when it can done. https://github.com/gcc-mirror/gcc/blob/master/gcc/config/nds32/nds32-cost.c
[Bug target/98596] registers not reused on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596 Jim Wilson changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-14 CC||wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson --- Part of the problem seems to be the use of volatile, as we disable optimizations inside volatile operations, and both constants are used inside volatile operations. But a bigger issue seems to be how we calculate constant costs. In riscv_rtx_costs we have /* If the constant is likely to be stored in a GPR, SETs of single-insn constants are as cheap as register sets; we never want to CSE them. */ if (cost == 1 && outer_code == SET) *total = 0; which tells the compiler that constants are cheaper than registers. If I change that to "*total = 1;" then the two constants get optimized. Changing this cost means we will likely extend register lifetimes and increase register pressure, which may reduce performance in some applications. We would need a lot of tersting to see what happens. We are already computing a cost of 0 for constants in the arithmetic immediate range, so setting costs to 0 here seems unnecessary, but it is hard to predict what might happen with this change. There might be something else I'm missing here.
