Re: [PATCH] LoongArch: Make -mstrict-align be configurable

[Huacai Chen]

Hi, Arnd,

On Thu, Feb 2, 2023 at 5:47 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Thu, Feb 2, 2023, at 09:42, Huacai Chen wrote:
> > Introduce Kconfig option ARCH_STRICT_ALIGN to make -mstrict-align be
> > configurable.
> >
> > Not all LoongArch cores support h/w unaligned access, we can use the
> > -mstrict-align build parameter to prevent unaligned accesses.
> >
> > This option is disabled by default to optimise for performance, but you
> > can enabled it manually if you want to run kernel on systems without h/w
> > unaligned access support.
> >
> > Signed-off-by: Huacai Chen <chenhuacai@xxxxxxxxxxx>
>
> This feels like it's a way too low-level option, I would not expect
> users to be able to answer this correctly.
>
> What I would do instead is to have Kconfig options for specific
> CPU implementations and derive the alignment requirements from
> that.
You mean provide something like CONFIG_CPU_XXXX as MIPS do?  That
seems not a good idea, too. If there are more than 3 CONFIG_CPU_XXXX,
the complexity is more than CONFIG_ARCH_STRICT_ALIGN. Then users are
also unable to do a correct selection. On the other hand, we can add
more words under CONFIG_ARCH_STRICT_ALIGN to describe which processors
support hardware unaligned accesses.

Huacai

>
> > +config ARCH_STRICT_ALIGN
> > +     bool "Enable -mstrict-align to prevent unaligned accesses"
> > +     help
> > +       Not all LoongArch cores support h/w unaligned access, we can use
> > +       -mstrict-align build parameter to prevent unaligned accesses.
> > +
> > +       This is disabled by default to optimise for performance, you can
> > +       enabled it manually if you want to run kernel on systems without
> > +       h/w unaligned access support.
> > +
>
>
> There is already a global CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> option, I think you should use that one instead of adding another
> one. Setting HAVE_EFFICIENT_UNALIGNED_ACCESS for CPUs that can
> do unaligned access will enable some important optimizations in
> the network stack and a few other places.
>
>     Arnd