From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84097 invoked by alias); 17 Mar 2015 01:20:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 84078 invoked by uid 89); 17 Mar 2015 01:20:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f172.google.com Received: from mail-pd0-f172.google.com (HELO mail-pd0-f172.google.com) (209.85.192.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 17 Mar 2015 01:20:08 +0000 Received: by pdbni2 with SMTP id ni2so74051772pdb.1 for ; Mon, 16 Mar 2015 18:20:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=l6mKybnmSzEebAH/a+i9iDvpUdLF2A82DOMjrEuc7hg=; b=NY/WNDlbMIYVF4S4yc47G+B5/h8LVugRV0fMalJMIicoOIGmfp+rFojK0Nl8RLknnC Pv2/lkYQOI8wP1mYfL7YyZoK9i4IroVjRbJ8tfEErFR6ImjlHcTq5HmYgfTMMD5YT85C Ww4u5jz6UqG0RJxrro1rocaY9LyyRsIeDprnwSyk739kRrQ0CWBap3Wvw0iSvAO6yFX7 Yk0pYLZAnh7xmdCUBSawRdwppwpZOxVLhg11lSo/vFlVB4o5RWv4cOdjbdlz4b4OL/UW w6PZoDdMYAOD/yInkGFUypQ+0SVp8lguWTEtiQA4qhPq54+GLEZigVWXI8bDr2yOgv3E gt6Q== X-Gm-Message-State: ALoCoQmTmAM/cFNheN/CaC9BndAOX4decJW8QFc3oR95ALIaoXUhSj8dNuXbec3vSU5Ofh99odJT X-Received: by 10.70.65.39 with SMTP id u7mr83715682pds.11.1426555206102; Mon, 16 Mar 2015 18:20:06 -0700 (PDT) Received: from [10.1.1.4] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by mx.google.com with ESMTPSA id nj5sm19282070pdb.24.2015.03.16.18.20.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 18:20:05 -0700 (PDT) Message-ID: <5507813E.3060106@linaro.org> Date: Tue, 17 Mar 2015 01:20:00 -0000 From: Kugan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kyrill Tkachov , "gcc-patches@gcc.gnu.org" CC: Marcus Shawcroft , Richard Earnshaw , Jim Wilson Subject: Re: [AArch64][PR65375] Fix RTX cost for vector SET References: <55066BCC.4010900@linaro.org> <5506AA24.3050108@arm.com> <5506CD7A.7030109@linaro.org> <5506D77B.5060909@linaro.org> <55070972.3000800@arm.com> In-Reply-To: <55070972.3000800@arm.com> Content-Type: multipart/mixed; boundary="------------020703060707060808080405" X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00857.txt.bz2 This is a multi-part message in MIME format. --------------020703060707060808080405 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-length: 2311 On 17/03/15 03:48, Kyrill Tkachov wrote: > > On 16/03/15 13:15, Kugan wrote: >> On 16/03/15 23:32, Kugan wrote: >>>>> lower-subreg.c:compute_costs() only cares about the cost of a (set >>>>> (reg) >>>>> (const_int )) move but I think the intention, at least for now, is to >>>>> return extra_cost->vect.alu for all the vector operations. >>>> Almost, what we want at the moment is COSTS_N_INSNS (1) + >>>> extra_cost->vect.alu >>> Thanks Kyrill for the review. >>> >>>>> Regression tested on aarch64-linux-gnu with no new regression. Is this >>>>> OK for trunk? >>>> Are you sure it's a (set (reg) (const_int)) that's being costed here? I >>>> thought for moves into vecto registers it would be a (set (reg) >>>> (const_vector)) which we don't handle in our rtx costs currently. I >>>> think the correct approach would be to extend the aarch64_rtx_costs >>>> switch statement to handle the CONST_VECT case. I believe you can use >>>> aarch64_simd_valid_immediate to check whether x is a valid immediate >>>> for >>>> a simd instruction and give it a cost of extra_cost->vect.alu. The >>>> logic >>>> should be similar to the CONST_INT case. >>> Sorry about the (set (reg) (const_int)) above. But the actual RTL that >>> is being split at 220r.subreg2 is >>> >>> (insn 11 10 12 2 (set (subreg:V4SF (reg/v:OI 77 [ __o ]) 0) >>> (subreg:V4SF (reg/v:OI 73 [ __o ]) 0)) >>> /home/kugan/work/builds/gcc-fsf-gcc/tools/lib/gcc/aarch64-none-linux-gnu/5.0.0/include/arm_neon.h:22625 >>> >>> 800 {*aarch64_simd_movv4sf} >>> (nil)) >>> >>> And also, if we return RTX cost above COSTS_N_INSNS (1), it will be >>> split and it dosent recover from there. Therefore we need something like >>> the below to prevent that happening. >>> >> Hi Kyrill, >> >> How about the attached patch? It is similar to what is currently done >> for scalar register move. > > Hi Kugan, > yeah, I think this is a better approach, though I can't approve. > Here is the patch with minor comment update. Regression tested on aarch64-linux-gnu with no new regression. Is this OK for trunk? Thanks, Kugan gcc/ChangeLog: 2015-03-17 Kugan Vivekanandarajah Jim Wilson PR target/65375 * config/aarch64/aarch64.c (aarch64_rtx_costs): Handle vector register copies. --------------020703060707060808080405 Content-Type: text/plain; charset=UTF-8; name="p.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="p.txt" Content-length: 971 diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index cba3c1a..d6ad0af 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -5544,10 +5544,17 @@ aarch64_rtx_costs (rtx x, int code, int outer ATTRIBUTE_UNUSED, /* Fall through. */ case REG: + if (VECTOR_MODE_P (GET_MODE (op0)) && REG_P (op1)) + { + /* The cost is 1 per vector-register copied. */ + int n_minus_1 = (GET_MODE_SIZE (GET_MODE (op0)) - 1) + / GET_MODE_SIZE (V4SImode); + *cost = COSTS_N_INSNS (n_minus_1 + 1); + } /* const0_rtx is in general free, but we will use an instruction to set a register to 0. */ - if (REG_P (op1) || op1 == const0_rtx) - { + else if (REG_P (op1) || op1 == const0_rtx) + { /* The cost is 1 per register copied. */ int n_minus_1 = (GET_MODE_SIZE (GET_MODE (op0)) - 1) / UNITS_PER_WORD; --------------020703060707060808080405--