This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb
- From: "Kyrylo Tkachov" <kyrylo dot tkachov at arm dot com>
- To: "Ramana Radhakrishnan" <Ramana dot Radhakrishnan at arm dot com>, "Julian Brown" <julian at codesourcery dot com>
- Cc: "gcc-patches" <gcc-patches at gcc dot gnu dot org>, "Richard Earnshaw" <Richard dot Earnshaw at arm dot com>
- Date: Tue, 13 Aug 2013 15:57:47 +0100
- Subject: RE: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb
- References: <005101ce9445$c27e6280$477b2780$ at tkachov@arm.com> <20130809110108 dot 4b63b456 at octopus> <5204CB97 dot 6050205 at arm dot com>
>
> On 08/09/13 11:01, Julian Brown wrote:
> > On Thu, 8 Aug 2013 15:44:17 +0100
> > Kyrylo Tkachov <kyrylo.tkachov@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
> >