This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH ARM]Handle REG addressing mode in output_move_neon explicitly
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: ramrad01 at arm dot com
- Cc: "bin.cheng" <bin dot cheng at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 2 Jul 2014 13:46:12 +0100
- 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> <004301cf6832$aee35020$0ca9f060$ at arm dot com> <CAJA7tRYwPRJCjFWgzrXiLZhTWrqKGJi8+Y9DORNQnptK_-7z4Q at mail dot gmail dot com>
On Wed, Jul 2, 2014 at 7:48 AM, Ramana Radhakrishnan
> On Mon, May 5, 2014 at 8:21 AM, bin.cheng <firstname.lastname@example.org> wrote:
>>> -----Original Message-----
>>> From: Richard Earnshaw
>>> Sent: Thursday, May 01, 2014 10:03 PM
>>> To: Bin Cheng
>>> Cc: email@example.com
>>> 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
>>> 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.
> Are the tests in the memset inlining patch now sufficient to expose
> the problem or do we need another test ?
Yes, it's covered by the 4th/7th test cases in memset inlining patch.