This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM] Misaligned access support for ARM Neon
- From: Ira Rosen <IRAR at il dot ibm dot com>
- To: Julian Brown <julian at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Paul Brook <paul at codesourcery dot com>, Richard Earnshaw <rearnsha at arm dot com>
- Date: Wed, 4 Aug 2010 09:38:43 +0300
- Subject: Re: [PATCH, ARM] Misaligned access support for ARM Neon
- References: <20091117171931.053faec2@rex.config> <1259593368.6000.40.camel@e200601-lin.cambridge.arm.com> <20091218172204.3c0eab5b@rex.config> <200912211220.12265.paul@codesourcery.com> <20100518013108.5514d986@rex.config> <20100604135031.3d77a087@rex.config> <1275668777.6827.83.camel@e102346-lin.cambridge.arm.com> <20100607200848.0fe3ab59@rex.config> <20100803173200.33d079bf@rex.config>
Julian Brown <julian@codesourcery.com> wrote on 03/08/2010 07:32:00 PM:
> There remains a small amount of noise in testsuite results with this
> patch, i.e.:
>
> PASS -> FAIL: mthumb-march_armv7-a-mfpu_neon-mfloat-abi_softfp/
> gcc.sum:gcc.dg/ve
> ct/vect-72.c scan-tree-dump-times vect "Alignment of access forced
> using peeling
> " 0
>
> This fails because a loop containing both an unaligned load and an
> unaligned store is unpeeled, making the load aligned. It seems to be
> a valid thing to do, so I'm not sure why it's a failure.
The store is supposed to be aligned, and the test checks how we handle
unaligned load. If somehow peeling is done for the load, causing the store
to be unaligned, it is a valid thing to do, just make sure that it is also
reasonable for the target.
Ira