libc/aarch64: fix strlen() when flush-to-zero is set

[fuz]

Summary

Our SIMD-enhanced strlen() implementation for AArch64 uses
a floating-point comparison to compare a bit mask to zero.
This works fine under normal circumstances, but fails if
the FZ (flush-to-zero) flag is set in FPCR (the floating-point
control register) as then the CPU no longer distinguishes
denormals from zero.

This was not caught during testing; this flag is rarely set
and programs that do so rarely perform string manipulation.

Avoid this problem by using an integer comparison instead.
The performance impact seems to be small (about 0.5 %).

Test Plan

passes the test suite

[getz]

Looks good with regards to the function but the performance is dependent on the uarch, on the pi5 we get a 19% decrease in performance on long strings (> 1 << 30 bytes).
I think this is a reasonable trade-off for increased performance for short and medium length strings which is the common case.

[markmi_dsl-only.net]

lib/libc/aarch64/string/strlen.S

36

Is the possible change in conditions for when fmov x1, d0 happens in any way significant when x1 would end up with a different value (0) that the original code would avoid assigning x1 before .Lloop was used?

[getz]

lib/libc/aarch64/string/strlen.S

36

We avoid a move to a GPR for each iteration. This was still carried out in the original code once a match has been found as we need the index of the first match.