On Tue, 27 May 2014, Ramana Radhakrishnan wrote:
> >> 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.
> >
> > This change however has regressed gcc.dg/vect/vect-72.c on the
> > arm-linux-gnueabi target, -march=armv5te, in particular in 4.8.
>
> And what are all the configure flags you are using in case some one
> has to reproduce this issue ?
There was nothing relevant to code generation among these flags except
from --with-arch=armv5te, but this architecture selection I already
included above.
> > Beforehand the code fragment in question produced was:
> >
> > .L14:
> > sub r1, r3, #16
> > add r3, r3, #16
> > vld1.8 {q8}, [r1]
>
> vld1 allows a misaligned load.
>
> > cmp r3, r0
> > vst1.64 {d16-d17}, [r2:64]!
> > bne .L14
> >
> > Afterwards it is:
> >
> > .L14:
> > vldr d16, [r3, #-16]
> > vldr d17, [r3, #-8]
> > add r3, r3, #16
> > cmp r3, r1
> > vst1.64 {d16-d17}, [r2:64]!
> > bne .L14
> >
> > and the second VLDR instruction traps with SIGILL (the value in R3 is
> > 0x10b29, odd as you'd expect, pointing into `ib'). I don't know why and
> > especially why only the second of the two (regrettably I've been unable to
> > track down an instruction reference that'd be detailed enough to specify
> > what exceptions VLDR can produce and under what conditions).
>
> vldr will cause an unaligned access fault if the address is
> misaligned. The question is why is the address misaligned in this
> case.
The address is unaligned because odd indexes into `ib' are accessed,
which is defined as:
char ib[N+1];
I'd say the question is rather why VLDR is used to access that array where
clearly it can't be. The loop copies a chunk of data in 64-bit quantities
between two memory areas of which one is 64-bit aligned and the other is
not. So while 32-bit or 64-bit aligned accesses can still be used to do
it, they can't be for both areas at a time, unless some further data
manipulation is done such as shifting and merging.
Maciej
