GH-123894: Simplify ascii decode using unaligned loads

[rhpvorderman]

When working on #120212 I noticed that the code for ascii_decode could be worded much simpler.

The current code prevents unaligned loads, but on x86-64 unaligned loads are not necessarily slower. By using memcpy the compiler is allowed to force aligned loads on platforms that require it, while allowing unaligned loads on platforms that support it.
It simplifies the code and allows for easier manual unrolling if that is desired at a later point.

EDIT: I feel that this does not warrant a NEWS entry. So I haven't written one.

• Issue: Simplifying ascii-decode #123894

[picnixz]

While it's easier to read, I'm wondering whether the memcpy() calls could induce some overhead. We are copying many small parts and check for the ASCII_CHAR_MASK mask instead of one single large memcpy() and some pointer arithmetic behind.

[picnixz]

Not sure if we already discussed it but would _Py_ALIGN_DOWN(end, SIZEOF_SIZE_T) work?

[rhpvorderman]

Probably. Is using a macro here important?

[picnixz]

How are performances affected by those multiple memcpy() calls?

[rhpvorderman]

Memcpy isn't called. Memcpy with a given size gets optimized to a single load.

[rhpvorderman]

Q.E.D: https://godbolt.org/z/a9xdjfoq4

[picnixz]

Ah I see the ASM yes. I'd suggest reformulating the comment by saying that "When supported, compilers optimize memcpy() into a single LOAD instruction if the number of bytes to copy is a literal value".

I confirmed it on GCC, but is it the case for MSVC & clang by the way? (NVM, I posted before seeing your reply)

[ZeroIntensity]

I wasn't aware of any precedent for using size_t in the codebase. I do see that it was there beforehand, but maybe that was a mistake -- we should be using Py_ssize_t, shouldn't we?

[rhpvorderman]

This can be closed as the CPython maintainers prefer aligned loads: #120212 (comment)