>>
> This is the rebased patch, though the original one doesn't conflict with
> latest trunk. Is it OK?
Ok.
Ramana
>
> Thanks,
> bin
> -Original Message-
> From: Bin.Cheng [mailto:amker.ch...@gmail.com]
> Sent: Wednesday, July 02, 2014 1:46 PM
> To: Ramana Radhakrishnan
> Cc: Bin Cheng; Richard Earnshaw; gcc-patches
> Subject: Re: [PATCH ARM]Handle REG addressing mode in
> output_move_neon explic
> 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 mem
On Mon, May 5, 2014 at 8:21 AM, bin.cheng wrote:
>
>
>> -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
> -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
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,
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/memc
