Re: Unaligned access trade-offs for SFrame FRE layout

On Tue, Sep 16, 2025 at 9:44 AM Segher Boessenkool
<[email protected]> wrote:
>
> On Tue, Sep 16, 2025 at 09:32:30AM -0700, Fangrui Song wrote:
> > The read32le(p) function is either a standard read or a byte-swapped
> > read.
>
> You should never overcomplicate things by doing byte-swaps.  Instead,
> just say what you mean:
>
> u32 read32le(u8 *p)
> {
>         return p[0] + 0x100*p[1] + 0x10000*p[2] + 0x1000000*p[3];
> }
>
> or something like that.  The compiler can optimise such things just
> fine!  There is no need to go via extra indirections.
>
>
> Segher

I made a typo in my previous message.

> Instead of using a function like read32<del>be</deel>(config, p), where config->endian specifies the object file's endianness, or read32(p) with an internal endianness check, the code can simply use read32le(p).

When aarch64be or s390x also use little-endian format, a little-endian
host processing their object files can utilize read32le(p), which the
compiler will optimize to either a standard or byte-swapped read.
I refer to the compiler-generated machine code.

If aarch64be or s390x use a big-endian format, the consumer will need
an extra argument in the read32 function or a global context inside
read32.

I think ELF's design, which emphasizes natural size and alignment
guidelines for its control structures, is outdated.
https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf#leb128-among-variable-length-integer-encodings
Fortunately, we appear to have achieved some space savings without
needing to implement variable-length encoding. In case it's useful,
variable-length integer encodings like LEB128, PrefixVarInt, or
SuffixVarInt ( https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf#leb128-among-variable-length-integer-encodings
) could potentially help in certain scenarios. However, these
approaches might necessitate additional relocations to support RISC-V
and LoongArch linker relaxation.