[PATCH v3 0/5] riscv: Use __riscv_has_extension_{likely,unlikely}
Vivian Wang
wangruikang at iscas.ac.cn
Sat Oct 11 15:21:16 PDT 2025
On 10/11/25 19:28, Conor Dooley wrote:
> On Sat, Oct 11, 2025 at 07:35:42AM +0800, Vivian Wang wrote:
>> There are about a dozen uses of asm goto in arch/riscv just to select
>> between two code paths with the alternative mechanism. Convert them to
>> the existing helpers __riscv_has_extension_{likely,unlikely}.
>>
>> In each case, I have preserved the existing code's choice of asm goto
>> pattern while picking between "likely" and "unlikely", namely:
>>
>> ALTERNATIVE("j %l[no]", "nop", ...) -> "likely"
>> ALTERNATIVE("nop", "j %l[yes]", ...) -> "unlikely"
>>
>> Since the helpers are just implementations of these patterns, the
>> performance should be the same as before.
> Can you explain why you're opting for the __ variant, instead of the one
> without __? They should do the same thing in your cases, and resolve to
> the alternative, since the non-alternative function call will be
> unreachable and the assert is compiletime. There's currently no users of
> the __ prefixed versions outside of other extension detection helpers, and
> I think it should probably be kept that way if possible.
I agree that it's preferable to use the non-__ functions. I'll do that
in the next version.
The only real reason I had used the __ versions is so that it would be
equivalent to existing code, although as you said these should be
equivalent since the uses are already guarded behind.
The "pgtable" code currently isn't guarded behind CONFIG_ALTERNATIVE,
although now that I think about it, it should actually be preferable to
do a runtime check than to do a TLB cleaning, so that one should
probably be non-__ as well.
Thanks,
Vivian "dramforever" Wang
More information about the linux-riscv
mailing list