This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [ARM] Post-indexed addressing for NEON memory access
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Charles Baylis <charles dot baylis at linaro dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Thu, 5 Jun 2014 07:27:09 +0100
- Subject: Re: [PATCH] [ARM] Post-indexed addressing for NEON memory access
- Authentication-results: sourceware.org; auth=none
- References: <CADnVucAaG=uAZyxQGvyf5bqrmW8JfhfjCp84uCpVnf+=Tois5w at mail dot gmail dot com>
- Reply-to: ramrad01 at arm dot com
On Mon, Jun 2, 2014 at 5:47 PM, Charles Baylis
<charles.baylis@linaro.org> wrote:
> This patch adds support for post-indexed addressing for NEON structure
> memory accesses.
>
> For example VLD1.8 {d0}, [r0], r1
>
>
> Bootstrapped and checked on arm-unknown-gnueabihf using Qemu.
>
> Ok for trunk?
This looks like a reasonable start but this work doesn't look complete
to me yet.
Can you also look at the impact on performance of a range of
benchmarks especially a popular embedded one to see how this behaves
unless you have already done so ?
POST_INC, POST_MODIFY usually have a funny way of biting you with
either ivopts or the way in which address costs work. I think there
maybe further tweaks needed but for a first step I'd like to know what
the performance impact is.
I would also suggest running this through clyon's neon intrinsics
testsuite to see if that catches any issues especially with the large
vector modes.
regards
Ramana
>
>
> gcc/Changelog:
>
> 2014-06-02 Charles Baylis <charles.baylis@linaro.org>
>
> * config/arm/arm.c (neon_vector_mem_operand): Allow register
> POST_MODIFY for neon loads and stores.
> (arm_print_operand): Output post-index register for neon loads and
> stores.