> > On 08/09/13 11:01, Julian Brown wrote: > > On Thu, 8 Aug 2013 15:44:17 +0100 > > Kyrylo Tkachov <kyrylo.tkac...@arm.com> wrote: > > > >> Hi all, > >> > >> The recently added gcc.target/arm/pr58041.c test exposed a bug in the > >> backend. When compiling for NEON and with -mno-unaligned-access we > >> end up generating the vld1.64 and vst1.64 instructions instead of > >> doing the accesses one byte at a time like -mno-unaligned-access > >> expects. This patch fixes that by enabling the NEON expander and > >> insns that produce these instructions only when unaligned accesses > >> are allowed. > >> > >> Bootstrapped on arm-linux-gnueabihf. Tested arm-none-eabi on qemu. > >> > >> Ok for trunk and 4.8? > > > > I'm not sure if this is right, FWIW -- do the instructions in question > > trap if the CPU is set to disallow unaligned accesses? I thought that > > control bit only affected ARM core loads & stores, not NEON ones. > > Thinking again - the ARM-ARM says - the alignment check is for element > size, so an alternative might be to use vld1.8 instead to allow for this > at which point we might as well do something else with the test. I note > that these patterns are not allowed for BYTES_BIG_ENDIAN so that might > be a better alternative than completely disabling it.
Looking at the section on unaligned accesses, it seems that the ldrb/strb-class instructions are the only ones that are unaffected by the SCTLR.A bit and do not produce alignment faults in any case. The NEON load/store instructions, including vld1.8 can still cause an alignment fault when SCTLR.A is set. So it seems we can only use the byte-wise core memory instructions for unaligned data. Therefore it seems this approach is not overly conservative. What do other people think? Kyrill > > regards > Ramana > > > > HTH, > > > > Julian > >
