On Tue, 7 Jan 2020 at 17:06, Richard Earnshaw (lists)
<richard.earns...@arm.com> wrote:
>
> On 07/01/2020 15:57, Christophe Lyon wrote:
> > Hi,
> >
> > 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*.
> >
> > However, LLVM has -arm-assume-misaligned-load-store which disables
> > generation of ldrd/strd in such cases:
> > https://reviews.llvm.org/D17015?id=48020
> >
> > Would some equivalent be acceptable in GCC? I have a small patch that
> > seems to work.
> >
> > Thanks,
> >
> > Christophe
> >
>
> It sounds ill-conceived to me. Why just this case (ldrd/strd)? What
> about cases where we use ldm/stm which also can't tolerate misaligned
> accesses?
Sorry, I over-simplified. That would avoid generating ldrd/strd/ldm/stm.
>
> Unless the conditions for the option are well-defined, I don't think we
> should be doing things like this. In the long term it just leads to
> more bugs being reported when the user is bitten by their own wrong code.
>
Indeed.
The thing (as usual) is that users report that "it works with other
compilers"....
> R.
