Re: Unaligned access trade-offs for SFrame FRE layout

On 14.09.2025 16:39, Rainer Orth wrote:
>> On 12.09.2025 19:34, Indu Bhagat via Binutils wrote:
>>> TL;DR: Thinking and experimenting a bit on the possible approaches for 
>>> avoiding unaligned accesses in the SFrame FRE layout (in SFrame V3), I 
>>> am not convinced that avoiding unaligned accesses for performance is 
>>> worth it.  IMO, forsaking compactness for avoiding unaligned accesses is 
>>> not a good trade off for SFrame.
>>>
>>> Problem Statement
>>> On architectures such as x86_64, AArch64, and s390x, unaligned memory 
>>> accesses are handled transparently by the hardware but incur a 
>>> performance penalty.
>>
>> As you say in a reply, may incur. However, shouldn't we also consider
>> possible ports of SFrame to architectures which don't handle this as
>> transparently? Off the top of my head I don't, for example, recall
>> whether RISC-V requires unaligned accesses to be handled transparently
>> by the hardware.
> 
> look for STRICT_ALIGNMENT in the GCC sources in gcc/config.  While
> several are embedded targets, there's also sparc in that list.

But is this setting a good reference for the purpose here. For RISC-V it's
command line (?) controlled (TARGET_STRICT_ALIGN), despite the spec saying

"An EEI may not guarantee misaligned loads and stores are handled invisibly.
 In this case, loads and stores that are not naturally aligned may either
 complete execution successfully or raise an exception. The exception raised
 can be either an address-misaligned exception or an access-fault exception."

It's okay for gcc to make assumptions (assuming they're properly documented),
but I don't think such assumptions can be extended to a discussion like the
one here.

Jan