FAST_UNALIGNED was defined only inside the ARCH_X86 arm, where it records
that AVX-and-later cores stopped punishing unaligned vector loads. On ARM64
the macro was therefore undefined, which the preprocessor reads as zero, so
every arm64 build compiled the texture-upload path as though the punishment
existed.
It never did. LDR Q and LD1 take any address, and GSVector4i's load template
ignores its own `aligned` parameter and emits the same instruction either
way. So the callers were paying for a distinction with no machine behind it:
WriteImage tests the source address and the pitch on every call to choose
between three template instantiations of WriteImageBlock and
WriteImageColumn that, for 8- and 4-bit columns, compile to identical code.
For 32- and 16-bit columns the unaligned arm is not identical, but it is the
worse one — eight combining 64-bit loads instead of four 128-bit loads and a
swizzle.
Defining it collapses all of that. GSLocalMemoryMultiISA.cpp.o goes from
80,368 to 62,184 bytes of .text and from 58 emitted functions to 32, which
is what an I-cache on a handheld cares about. Only GSBlock.h and
GSLocalMemoryMultiISA.cpp read the macro, so nothing else moves.
The retained load strategy is not new code: whenever an upload happened to
land 32-byte aligned, arm64 already ran exactly this sequence. What goes
away is the arm that only ever ran when it did not.
Brian Degenhardt
a3bf73bf7a