[RFC PATCH 16/19] riscv: Add accelerated strcmp routines
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Fri Mar 31 14:48:43 GMT 2023
On 31/03/23 11:30, Jeff Law wrote:
>
>
> On 3/31/23 06:31, Adhemerval Zanella Netto wrote:
>
>>> Jeff
>>
>> Is this implementation really better than new generic one [1]? With a target
>> with zbb support, the generic word comparison should use orc.b instruction [2].
>> And the final comparison, once with the last word or the mismatch word is found,
>> should use clz/ctz instruction [3] (result also in branchless code, albeit
>> I have not check if better than the snippet this implementation uses).
> I haven't done any comparisons against the updated generic bits. I nearly suggested to Christoph to do that evaluation, but when I wandered around sysdeps I saw that we still had multiple custom strcmp implementations and set that suggestion aside.
>
>
>>
>> The generic implementation also has the advantage of use word instruction
>> on unaligned case, where this implementation does a naive byte per byte
>> check.
> Yea, but in my digging this just didn't happen terribly often. I don't think there's a lot of value there. Along the same lines, my investigation didn't show any significant value to realign cases and I nearly suggested dropping them to avoid the branch in the hot path, but I wasn't confident enough in the breadth of my investigations to push it.
> >>
>> So maybe a better option would to optimize further the generic implementation.
>> One option might be to parametrize the final_cmp so you can use the branchless
>> trick (if it indeed is better than generic code). Another option that the
>> generic implementation does not explore is manual loop unrolling, as done by
>> multiple assembly implementations.
> I could certainly support that. I was on the fence about pushing to use the generic bits, a little nudge could easily push me to that side.
The initial realign could be tuned, I added mostly because it simplifies both
aligned and unaligned case a lot. But it should be doable to use a similar
strategy as strchr/strlen to mask off the bits based on the input alignment.
The unaligned case is just to avoid drastic performance different between
input alignment, it is cheap and in the end should just be additional code
size.
But the main gain of using the generic implementation is one less assembly
routine to maintain and tune; and by improving the generic implementation
we gain in ecosystem as whole.
More information about the Libc-alpha
mailing list