[PATCH] riscv: avoid vle8ff in vector strcmp loop

[Jeff Law]

On 8/10/26 2:57 AM, daichengrong wrote:
>
> On 6/15/26 21:06, Carlos O'Donell wrote:
>> On 6/14/26 6:55 AM, daichengrong wrote:
>>> Limit vl by the minimum distance from the input pointers to the next 4K
>>> boundary, and use normal vle8.v loads in the main loop.  This keeps the
>>> loads page-safe while avoiding the vl update dependency from vle8ff.v.
>> Do you have microbenchmark data that supports this change?
>>
>> Generally for such changes we would like to see "make bench" showing a difference.
> Sorry, my previous reply with the benchmark results was accidentally sent
> outside this thread. Reposting the results here to keep the discussion
> in the proper thread.
>
> I ran the benchmark on the SpacemiT K3 platform.
>
> The comparison is between the current __strcmp_vector implementation in
> the git tree and the new implementation in this patch.
>
> The main purpose of this patch is to avoid using vle8ff.v in the common
> strcmp vector loop.  The strcmp implementation itself does not know the
> string length in advance.  It only uses the current pointer values to
> compute the distance from both input pointers to the next 4K boundary.
>
> The smaller distance is used to limit vl, and then normal vle8.v loads
> are used.  This keeps the vector loads from crossing a 4K boundary while
> avoiding the vl update dependency from vle8ff.v.
>
> For the benchmark analysis, I grouped the test cases by the benchmark
> string length.  This is only for presenting the results; the
> implementation itself does not use the length.
>
> Grouped by benchmark string length:
>
> Len bucket  N     Git_t     New_t    Speedup
> --------------------------------------------
> 0-256       4048  42.091    38.438   1.10x
> 257-511     490   229.183   69.731   3.29x
> 512-1023    98    292.148   91.323   3.20x
> 1024-2047   98    564.029   149.398  3.78x
> 2048-4095   70    1109.365  278.249  3.99x
> 4096-8191   70    2197.762  474.719  4.63x
>
> Since the patch changes the page-boundary handling, I also grouped the
> results by the smaller distance of the two input pointers to the next 4K
> boundary:
>
> Page dist  N     Git_t    New_t    Speedup
> ------------------------------------------
> 1-16       966   144.690  68.287   2.12x
> 17-32      1026  52.423   49.389   1.06x
> 33-64      841   95.930   42.210   2.27x
> 65-128     682   94.812   31.330   3.03x
> 129-256    393   112.647  65.460   1.72x
> 256        966   222.487  69.186   3.22x
THanks a ton for all this.  It does make me wonder if this should be a 
K1/K3 specific path rather than modifying the generic RVV strcmp path.  
It seems the K1/K3 design doesn't handle FoF as well as it could.  
That's probably the root cause of strlen using Zbb performing better 
than RVV on the K1/K3 designs as well.

Jeff