Re: Unaligned access trade-offs for SFrame FRE layout

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.

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.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University