public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kugan <kugan.vivekanandarajah@linaro.org>
To: Kyrill Tkachov <kyrylo.tkachov@arm.com>,
	 "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: Marcus Shawcroft <Marcus.Shawcroft@arm.com>,
	 Richard Earnshaw <Richard.Earnshaw@arm.com>,
	Jim Wilson <jim.wilson@linaro.org>
Subject: Re: [AArch64][PR65375] Fix RTX cost for vector SET
Date: Thu, 26 Mar 2015 07:22:00 -0000	[thread overview]
Message-ID: <5513B390.2030201@linaro.org> (raw)
In-Reply-To: <5507813E.3060106@linaro.org>

ping?

Thanks,
Kugan

On 17/03/15 12:19, Kugan wrote:
> 
> 
> 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  <kuganv@linaro.org>
>             Jim Wilson  <jim.wilson@linaro.org>
> 
> 	PR target/65375
> 	* config/aarch64/aarch64.c (aarch64_rtx_costs): Handle
> 	vector register copies.
> 
> 
> 

  reply	other threads:[~2015-03-26  7:22 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16  5:36 Kugan
2015-03-16 10:02 ` Kyrill Tkachov
2015-03-16 12:33   ` Kugan
2015-03-16 13:15     ` Kugan
2015-03-16 16:42       ` Jim Wilson
2015-03-16 16:49       ` Kyrill Tkachov
2015-03-17  1:20         ` Kugan
2015-03-26  7:22           ` Kugan [this message]
2015-04-14 22:09             ` Kugan
2015-04-15  9:25               ` James Greenhalgh
2015-04-15 10:14                 ` Kyrill Tkachov
2015-04-15 11:05                   ` James Greenhalgh
2015-04-15 11:17                     ` Kyrill Tkachov
2015-04-15 10:45                 ` Kugan
2015-04-15 11:18                   ` James Greenhalgh
2015-04-15 11:33                     ` Kugan
2015-04-17 11:19                       ` Kugan
2015-04-17 11:25                         ` Kyrill Tkachov
2015-04-20 20:22                         ` James Greenhalgh
2015-04-24 23:26                           ` Kugan
2015-04-24 23:30                             ` [ARM] " Kugan
2015-04-27 11:02                               ` Kyrill Tkachov
2015-05-05  6:17                             ` [AArch64][PR65375] " James Greenhalgh
2015-05-06  2:12                               ` Kugan
2015-05-07  7:24                                 ` James Greenhalgh
2015-05-20  3:32                                   ` Kugan
2015-04-15 11:35                     ` Maxim Kuvyrkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5513B390.2030201@linaro.org \
    --to=kugan.vivekanandarajah@linaro.org \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jim.wilson@linaro.org \
    --cc=kyrylo.tkachov@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).