From patchwork Fri Jul 4 12:20:10 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bin Cheng X-Patchwork-Id: 367092 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46F201400BB for ; Fri, 4 Jul 2014 22:20:25 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; q=dns; s=default; b=VoSsLEQH63q1b2u9 3UEysrJrQMGFOoRmaZe3rV7IeSVe15D3fH+t1sQcH71Jy22BwcqVU51ume75jfme s1Mnohc6r0RxXG7jmQmjU66/m5xVAcC4Ja0dG1hVUfQTo2HuxJEnyRsRVvYz0Fkq BTteIz4X3P6/3yZXUa9zBTJeSBo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=default; bh=9+/Nyx8SKM4IIHblyNLzF8 kPRXw=; b=G7unF76d1zGoufrjB0RXkKw7GV/JgkGR72Ahr/snFSAIbDiC9I+MCa 1heW+xqrgvr5JUCaJG70Ai+1cmbduMKc6/BcJJY93rgZsXN1DfAzK6OdOg0dN3tb Z5uezPcjxku28EOY1XwibWpiVWRaKEkplN/lXP17/KOh0C5WUXUos= Received: (qmail 10550 invoked by alias); 4 Jul 2014 12:20:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 10514 invoked by uid 89); 4 Jul 2014 12:20:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Jul 2014 12:20:15 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Fri, 04 Jul 2014 13:20:13 +0100 Received: from shawin233 ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2014 13:20:10 +0100 From: "Bin Cheng" To: "'Bin.Cheng'" , "Ramana Radhakrishnan" Cc: "Richard Earnshaw" , "gcc-patches" References: <002f01cf6357$854c7a00$8fe56e00$@arm.com> <5362542B.6060609@arm.com> <004301cf6832$aee35020$0ca9f060$@arm.com> In-Reply-To: Subject: RE: [PATCH ARM]Handle REG addressing mode in output_move_neon explicitly Date: Fri, 4 Jul 2014 13:20:10 +0100 Message-ID: <000701cf9782$4d02b740$e70825c0$@arm.com> MIME-Version: 1.0 X-MC-Unique: 114070413201300601 X-IsSubscribed: yes > -----Original Message----- > From: Bin.Cheng [mailto:amker.cheng@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 explicitly > > On Wed, Jul 2, 2014 at 7:48 AM, Ramana Radhakrishnan > wrote: > > 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 > >>> 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 ? > > Yes, it's covered by the 4th/7th test cases in memset inlining patch. > This is the rebased patch, though the original one doesn't conflict with latest trunk. Is it OK? Thanks, bin Index: gcc/config/arm/arm.c =================================================================== --- gcc/config/arm/arm.c (revision 212295) +++ gcc/config/arm/arm.c (working copy) @@ -18454,6 +18498,20 @@ output_move_neon (rtx *operands) /* FIXME: Not currently enabled in neon_vector_mem_operand. */ gcc_unreachable (); + case REG: + /* We have to use vldm / vstm for too-large modes. */ + if (nregs > 1) + { + if (nregs > 4) + templ = "v%smia%%?\t%%m0, %%h1"; + else + templ = "v%s1.64\t%%h1, %%A0"; + + ops[0] = mem; + ops[1] = reg; + break; + } + /* Fall through. */ case LABEL_REF: case PLUS: { @@ -18487,14 +18545,7 @@ output_move_neon (rtx *operands) } default: - /* We have to use vldm / vstm for too-large modes. */ - if (nregs > 4) - templ = "v%smia%%?\t%%m0, %%h1"; - else - templ = "v%s1.64\t%%h1, %%A0"; - - ops[0] = mem; - ops[1] = reg; + gcc_unreachable (); } sprintf (buff, templ, load ? "ld" : "st");