Hi Julian, > > 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.
Looking at the architecture reference, the SCTLR.A bit also affects the NEON instructions. When it's set to 1, they produce an alignment fault, the same as all the other load/store instructions. Also, reading the gcc documentation for the -mno-unaligned-access option, it says: "If unaligned access is not enabled then words in packed data structures will be accessed a byte at a time" So using vld1.64 and vst1.64 is definitely against that, since they access 64 bits at a time. > Not to say the test case you mention isn't broken anyway, for some > other reason -- but I don't think disabling NEON movmisalign > for !unaligned_access is the right way to fix it. > > HTH, Thanks, Kyrill > > Julian
