This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH ARM]Handle REG addressing mode in output_move_neon explicitly
- From: "bin.cheng" <bin dot cheng at arm dot com>
- To: "Richard Earnshaw" <Richard dot Earnshaw at arm dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 5 May 2014 15:21:49 +0800
- Subject: RE: [PATCH ARM]Handle REG addressing mode in output_move_neon explicitly
- Authentication-results: sourceware.org; auth=none
- References: <002f01cf6357$854c7a00$8fe56e00$ at arm dot com> <5362542B dot 6060609 at arm dot com>
> -----Original Message-----
> From: Richard Earnshaw
> Sent: Thursday, May 01, 2014 10:03 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM]Handle REG addressing mode in
> output_move_neon explicitly
>
> On 29/04/14 04:02, bin.cheng wrote:
> > Hi,
> > Function output_move_neon now generates vld1.64 for memory ref like
> > "dx <- [r1:SI]", this is bogus because it requires at least 64-bit
> > alignment for 32-bit aligned memory ref. It works now because GCC
> > doesn't generate such insns in the first place, but things are going
> > to change if memset/memcpy calls are inlined by using neon instructions.
> >
>
> V[LD/ST]1.64 only need to be 64-bit aligned if strict alignment is
enabled. We
> normally assume that not to be the case. The exception to this is when an
theoretically, this doesn't make the problem go away, right?
> explicit alignment check is used in the address expression (the :64
suffix),
> which causes the address to be checked for strict alignment at all times.
>
> Do you have a testcase?
I can't provide a test case without the memset inlining patch.
Thanks,
bin