Hi Alexey,
On 10/2/26 12:04 PM, Alexey Charkov wrote:
ARM passes -mstrict-align (-mno-unaligned-access on ARMv7) to everything,
because when the MMU is off any unaligned access there faults. The
compiler then has to assemble every wide unaligned load out of single
bytes: one ldr becomes eight ldrb and seven orr/lsl.
This is especially painful for decompressors which refill their buffer
in 64-bit words. On a Rockchip RK3576 SPL, zstd unpacks a 30MiB Falcon
mode Linux kernel in 1947ms built this way and 596ms without the flag,
and the SPL gets 2.3KiB smaller by cutting down on the byte-wise loads and
ORs. gzip, whose inflate walks its input a byte at a time anyway, gains
6%.
Add ASSUME_UNALIGNED_ACCESS_OK for a platform to state that the MMU is on
by the time it unpacks an image, and let the decompression libraries drop
the flag when it is set. The arch exports the flag it added rather than
lib/ naming it, so this stays correct for anything else which adds one.
No functional change anywhere until the symbol is selected.
Signed-off-by: Alexey Charkov <[email protected]>
---
arch/Kconfig | 35 +++++++++++++++++++++++++++++++++++
arch/arm/cpu/armv7/config.mk | 3 +++
arch/arm/cpu/armv8/config.mk | 3 +++
lib/Makefile | 3 +++
lib/lzma/Makefile | 8 ++++++++
lib/lzo/Makefile | 8 ++++++++
lib/zlib/Makefile | 8 ++++++++
lib/zstd/Makefile | 8 ++++++++
8 files changed, 76 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 8d63afeb138e..606b9d79ecd8 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -27,6 +27,41 @@ config SUPPORT_LITTLE_ENDIAN
bool
default y if !SUPPORT_BIG_ENDIAN
+config ASSUME_UNALIGNED_ACCESS_OK
I only see changes in ARM and ARM64 config.mk, should this (and SPL)
symbol depends on ARM/ARM64 maybe? I see in the second patch you're
adding another dependency on !SPL_SYS_DCACHE_OFF, any reason for it not
to be a dependency in the main symbol in this file here?
This is very compressor/decompressor-specific, should we rename the
symbol so it's clear only those would/should be impacted by this symbol
(hoping that its usage doesn't get extended in the future).
+ bool
+ help
+ Assume that an unaligned access cannot fault by the time U-Boot
+ proper unpacks an image, and build the decompression libraries
+ without the architecture's strict-alignment flag on that basis.
+
+ Architectures whose unaligned accesses fault while the MMU is off
+ pass such a flag to everything, which makes the compiler assemble
+ each wide unaligned load out of single bytes. That is both slower
+ and larger, and a decompressor refilling its bit buffer in machine
+ words can spend up to four times as long for it.
+
+ The assumption holds only once the MMU is on, which on most
+ platforms has not happened by the time an image is unpacked, and
+ nothing checks it. Select it from code which enables the MMU
Crazy idea, but should we add a flag that specifies whether the MMU (and
dcache?) has been set up, and then read that flag in places where we
have this assumption? Then we could at least clearly hard fail on this
flag not being set and tell the user something went wrong before the
system does a HW fault by itself?
Cheers,
Quentin
