libs/libc/string: Copy and compare by words when pointers agree on alignment.

[Fishwaldo]

Summary

The BSD string functions choose a word-at-a-time path only when both pointers are
aligned, and a byte-at-a-time path otherwise. That leaves a common case on the slow
path: a pair sitting at the same offset from a boundary. Copying or comparing a few
leading bytes aligns both at once, because aligning one aligns the other.

This adds MISALIGNED(), which asks whether two pointers disagree about where a
boundary falls, and walks an agreeing pair up to the boundary before the existing
path selection runs. MISALIGNED4() does the same for the 4-byte path added by
#19870, so a pair that is 4-byte but not 8-byte aligned now reaches the wide path
rather than the middle one.

Nine functions have such a gate and all nine are covered: memcpy, memccpy,
memcmp, strcpy, stpcpy, strncpy, stpncpy, strcmp, strncmp.

A pair at differing offsets is deliberately untouched. No single boundary serves
both, so there is nothing to walk to.

The diff adds 187 lines and removes none. Every existing alignment test, word
loop and byte loop is preserved verbatim; the walk is a new step ahead of them. That
keeps the change easy to review and easy to revert.

Relationship to #19870

#19870 widened these functions to long long and added a 4-byte middle path, which
covers pairs that are both 4-byte aligned. It does not cover equal offsets that are
not multiples of four: UNALIGNED() is the OR of both pointers, so s+1/d+1 fails
both gates and still reaches the byte loop. That is the gap here.

Measurements

EIC7700 EVB (EIC7700X, 4 x RV64GC, 1.4 GHz), kernel build, CONFIG_ALLOW_BSD_COMPONENTS
and CONFIG_LIBC_NEWLIB_OPTSPEED set, every CONFIG_RISCV_* string option disabled so
the C implementations are the ones under test. Benchmark from apps#3706. Medians of 3
runs, MB/s, at its largest size (32 KiB for the mem functions, 4 KiB for the str ones):

	equal offset s+1/d+1		aligned s+0/d+0
memcpy	414 → 4148	10.0x	4214 → 4208
memcmp	41 → 361	8.8x	362 → 360
strncmp	28 → 202	7.4x	207 → 207
strcmp	42 → 273	6.5x	278 → 276
strncpy	377 → 1676	4.5x	1824 → 1748
stpncpy	376 → 1654	4.4x	1843 → 1724
stpcpy	551 → 1833	3.3x	1970 → 1939
memccpy	650 → 2012	3.1x	2478 → 2016
strcpy	636 → 1837	2.9x	1678 → 1965

The same run set was taken with an independent earlier version of the benchmark and
agreed on every gain to within a few percent.

Cases the walk never runs for move in both directions by up to a third: strcpy
aligned improves 1.17x, memccpy at differing offsets drops to 0.64x. The code on
those paths is unchanged, so that is code placement rather than an effect of the
change.

This has only been measured on RISC-V

The change itself is architecture independent, and so is the reasoning behind it, but
every number above comes from one RV64GC core. Three things that decide whether the
trade is as good elsewhere all vary by architecture:

• The cost of the walk. It is bounded by sizeof(libc_data_t) - 1 bytes, so it is
  cheaper relative to the transfer on a 32-bit target than on this 64-bit one.
• The value of reaching the word path. Here the byte loop runs at roughly a tenth
  of word speed. On a core where misaligned or byte access is comparatively cheaper,
  the gain shrinks; on one where unaligned word access traps to a fixup handler, the
  arithmetic changes again.
• Byte loop codegen. The placement variation noted above is a property of this
  core and this compiler, not of the patch, and will land differently elsewhere.

I would welcome numbers from ARM, Xtensa or a 32-bit RISC-V target before this is
taken as generally beneficial. If it turns out to be a win only on some
architectures, the walk is small and self-contained enough to sit behind a
configuration option instead.

Alternatives considered

Two other shapes were built and measured on hardware: the same walk written with
early returns, and changing the gate conditions in place from "both aligned" to
"agree" with the walk inside the branch. All three produce the same gains and differ
only in which untouched paths land well or badly. This one was chosen because it
modifies no existing line.

Testing

tools/checkpatch.sh clean. nxstyle clean on all 10 files.

Correctness comes from the arch_libc test sweeps, which cover exactly what the walk
could break: source and destination offsets 0-3 x 0-3 for memcmp and 0-7 x 0-7 for
the strcmp/strncmp/strncpy/stpcpy family, at every size boundary, with the
difference or terminator placed at each position in turn.

== string correctness ==
  memcpy     correctness: ok (0 bad)
  memmove    correctness: ok (0 bad)
  mv-overlap correctness: ok (0 bad)
  memset     correctness: ok (0 bad)
  memcmp     correctness: ok (0 bad)
  str-scan   correctness: ok (0 bad)
  strcmp-fam correctness: ok (0 bad)
  strlcpy    correctness: ok (0 bad)
== string fails: 0 ==

The cases needing most care were the counted ones. strncmp's byte tail returns
*cs - *ct when its count is exhausted, so its walk returns 0 itself rather than
falling through. strncpy and stpncpy must not let a terminator found during the
walk reach the word loop, and must still pad to exactly n; both leave the
terminator for the byte loop, which pads. stpcpy and stpncpy return the address
of the terminator, which the walk preserves.

Notes for reviewers

• No in-tree configuration selects the BSD string functions on a target CI builds,
  so a green run does not exercise this code at all. The measurements above are the
  only evidence, and they are from a single architecture.
• Pairs agreeing modulo 4 but not modulo 8 and not themselves 4-byte aligned
  (s+1/d+5 and its mirrors, 6 of 64 offset-pair residues) still take the byte path.
  Baseline does too, so it is not a regression, just unexploited.
• apps#3706 does not link in a kernel build: the per-function tests in
  arch_libc_test_main.c call perf_gettime(), which is arch-internal and absent
  from syscall.csv. The benchmark itself is fine. Reproducing the table above needs
  CONFIG_TESTING_ARCH_LIBC_BENCH=y with the per-function test options off. I will
  fix that separately in apps.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[xiaoxiang781216]

@Fishwaldo could you apply this change on top of #19870? The change will be more simpler.

[Fishwaldo]

Hi @xiaoxiang781216 I'll rebase once #19870 lands.

[Fishwaldo]

@xiaoxiang781216 done!