On Tue, 7 Jan 2020 at 17:33, Christophe Lyon <christophe.l...@linaro.org> wrote:
>
> On Tue, 7 Jan 2020 at 17:18, Marc Glisse <marc.gli...@inria.fr> wrote:
> >
> > On Tue, 7 Jan 2020, Christophe Lyon wrote:
> >
> > > I've received a support request where GCC generates strd/ldrd which
> > > require aligned memory addresses, while the user code actually
> > > provides sub-aligned pointers.
> > >
> > > The sample code is derived from CMSIS:
> > > #define __SIMD32_TYPE int
> > > #define __SIMD32(addr) (*(__SIMD32_TYPE **) & (addr))
> > >
> > > void foo(short *pDst, int in1, int in2) {
> > > *__SIMD32(pDst)++ = in1;
> > > *__SIMD32(pDst)++ = in2;
> > > }
> > >
> > > compiled with arm-none-eabi-gcc -mcpu=cortex-m7 CMSIS.c -S -O2
> > > generates:
> > > foo:
> > > strd r1, r2, [r0]
> > > bx lr
> > >
> > > Using -mno-unaligned-access of course makes no change, since the code
> > > is lying to the compiler by casting short* to int*.
> >
> > If the issue is as well isolated as this, can't they just edit the code?
> >
> > typedef int __SIMD32_TYPE __attribute__((aligned(1)));
> >
>
> That type is defined by a macro in CMSIS's arm_math.h.
> I think users don't want to play tricks with such libraries,
> but I could try to check with them if something around these lines
> would be acceptable.
>
Actually I got a confirmation of what I suspected: the offending function foo()
is part of ARM CMSIS libraries, although the users are able to recompile them,
they don't want to modify that source code. Having a compilation option to
avoid generating problematic code sequences would be OK for them.
So from the user's perspective, the wrong code is part of a 3rd party library
which they can recompile but do not want to modify.
> > gets
> >
> > str r1, [r0] @ unaligned
> > str r2, [r0, #4] @ unaligned
> >
> > instead of
> >
> > strd r1, r2, [r0]
> >
> > --
> > Marc Glisse
