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

Reply via email to