Re: [PATCH next] i386: Remove string functions that use 'rep scasb'

From: Andy Shevchenko

Date: Mon Mar 30 2026 - 13:22:41 EST


On Mon, Mar 30, 2026 at 7:58 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>
> On 3/27/26 12:57, david.laight.linux@xxxxxxxxx wrote:
> > The fixed overhead of all the 'rep xxx' instructions is rather more
> > that might expect. While 'rep movs' is getting better on more recent
> > CPU, the same is not true for 'rep scasb'. On my Zen-5 it has a
> > fixed overhead of 150 clocks and then takes 3 clocks for each byte.
> > I've not measured any Intel CPU, but the cost might be 'only' 40 +
> > 2n.
>
> One measurement on a modern 64-bit CPU isn't super convincing to me.
>
> > Remove the asm versions of strcat() strncat() strlen() memchr()
> > and memscan(), the generic C versions will be faster.
> >
> > It is quite likely that all these functions are slower than the generic
> > code on pretty much all CPU since the 486.
>
> This is rather handwavy for my taste.
>
> There seem to be two valid paths here:
>
> 1. We continue the "nobody cares about 32-bit" refrain. This removes a
> bunch of 32-bit-only code and complexity. If it causes a performance
> regression, we do not care much.
> 2. Someone makes _some_ kind of effort to test this on at least *one*
> 32-bit-only CPU to see if it does any harm.
>
> In other words, I'm not opposed to the patch, but the justification
> doesn't really work for me as written.

I have Intel Quark at hand to test. But I need to know the
step-by-step instructions on what to do.

--
With Best Regards,
Andy Shevchenko