On Tue, 8 Apr 2025 07:07:12 GMT, Fei Yang <fy...@openjdk.org> wrote: > Maybe we should check UseZicond and only enable UseCMoveUnconditionally & > ConditionalMoveLimit conditionally?
Not sure what do you mean here. > I don't see how enabling CMove will bring us any performance benefit without > Zicond. It's done with conditional branches in CPU backend as well. I add the performance result in desc. There are 2 optimization scenarios, one is cmove itself, another is when cmove can be transform to a min/max in some condition. > src/hotspot/cpu/riscv/vm_version_riscv.cpp line 461: > >> 459: FLAG_SET_DEFAULT(UseZicond, false); >> 460: warning("UseZicond is turned off automatically. Turn it on with >> -XX:+UseZicond explicitly."); >> 461: } > > Does this mean `UseZicond` could not be enabled on the command line? And I > witnessed quite some warning when doing a native build. If `UseZicond` causes > regression for some cases, is it more reasonable to not auto-enable it > through hwprobe [1]? Or only enable it for debug builds like > https://github.com/openjdk/jdk/pull/24478 does? > > [1] > https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L228 This is to not enable Zicond automatically, but user can still turn it on manually if they want to try or make sure it bring benefit on the specific hardware. Currently it's based on bananapi result, so maybe in the future we should adjust the default value of UseZicond. I'm fine with either default value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2032893506 PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2032893370