Re: Unaligned access trade-offs for SFrame FRE layout

On 14.09.2025 18:18, Rainer Orth wrote:
> Jan Beulich <[email protected]> writes:
> 
>> 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.
> 
> please look at the actual code:
> 
> gcc/config/riscv/riscv.cc:           TARGET_STRICT_ALIGN ? 0 : 1);
> 
> on RISC-V, the setting is controlled by -mstrict-align.  On most others,
> it's just 1.

Precisely my point: By (not or wrongly) using the command line option, you
can break things. Whereas such breakage wants avoiding here.

> I'm just pointing out an easy way to answer the question: there's a
> considerable number of strict-alignment targets.  If they is relevant to
> the discussion at hand is for the SFrame developers to decide: if they
> come to the conclusion that none of the affected CPUs is of interest,
> that's certainly fine.  However, from my recently experience porting
> LLVMs openmp to SPARC, fixing this as an afterthought takes some time
> and analysis, so you need to decide if you want to support such targets
> or not.

Yes, that's exactly why I brought up the point.

Jan