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