This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH ARM]Handle REG addressing mode in output_move_neon explicitly


On Mon, May 5, 2014 at 8:21 AM, bin.cheng <bin.cheng@arm.com> 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
>> 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.
>
Are the tests in the memset inlining patch now sufficient to expose
the problem or do we need another test ?

Ramana
> Thanks,
> bin
>
>
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]