RFR: 8344306: RISC-V: Add zicond

Robbin Ehn rehn at openjdk.org
Tue Nov 26 10:43:38 UTC 2024


On Tue, 26 Nov 2024 10:23:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> In cpu models we save ~1 cycle per removed branch.
>> This patch removes ~0.1% of branches in generic C2 generated code.
>> We should probably investigate if we can improve/add peephole optimization to remove more branches.
>> 
>> As the C1 cmov code is a bit tricky I left that as a followup.
>> 
>> I added gtests for the cmovs.
>> (we should add coverage for more of masm in this gtest suit)
>> Pro tip, invoke the gtestLauncher directly (you only need to build exploded):
>> `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2`
>> 
>> Tested on Spacemit X60, gtests and tier1.
>> 
>> Thanks, Robbin
>
> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2047:
> 
>> 2045:       assert(false, "unsupported compare condition");
>> 2046:       ShouldNotReachHere();
>> 2047:   }
> 
> Seems we can use the similar way in `C2_MacroAssembler::cmp_branch` +`conditional_branches` to simplify the code.

The "BoolTest" is a C2 construct, C1 uses LIR_Condition, there is no generic test enum.
So you would need one table to translate from C2 -> masm and one from C1 -> masm, and then one table to pick the correct version.

You can turn any switch statement into a table with function pointers, but:
`cmp_branch(cmpFlag ^ (1 << neg_cond_bits), op1, op2, L);`
Trying to figure out which compare is selected is shoter, yes, but much more complex IMHO.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1858238759


More information about the hotspot-dev mailing list