public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Ramana Radhakrishnan <ramana.radhakrishnan@foss.arm.com>
Cc: Bill Schmidt <wschmidt@linux.vnet.ibm.com>,
		Richard Sandiford <richard.sandiford@arm.com>,
		Ramana Radhakrishnan <ramana.gcc@googlemail.com>,
	Alan Hayward <Alan.Hayward@arm.com>,
		"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] vectorizing conditional expressions (PR tree-optimization/65947)
Date: Tue, 15 Sep 2015 11:47:00 -0000	[thread overview]
Message-ID: <CAFiYyc009gsc=6a=X0X=B3G2mpnuS+hhUeh+888FVDT_kDovbQ@mail.gmail.com> (raw)
In-Reply-To: <55F30169.60808@foss.arm.com>

On Fri, Sep 11, 2015 at 6:29 PM, Ramana Radhakrishnan
<ramana.radhakrishnan@foss.arm.com> wrote:
>
>>>> Saying that all reductions have equivalent performance is unlikely to be
>>>> true for many platforms.  On PowerPC, for example, a PLUS reduction has
>>>> very different cost from a MAX reduction.  If the model isn't
>>>> fine-grained enough, let's please be aggressive about fixing it.  I'm
>>>> fine if it's a separate patch, but in my mind this shouldn't be allowed
>>>> to languish.
>>>
>>> ...I agree that the general vectoriser cost model could probably be
>>> improved, but it seems fairer for that improvement to be done by whoever
>>> adds the patterns that need it.
>>
>> All right.  But in response to Ramana's comment, are all relevant
>> reductions of similar cost on each ARM platform?  Obviously they don't
>> have the same cost on different platforms, but the question is whether a
>> reduc_plus, reduc_max, etc., has identical cost on each individual
>> platform.  If not, ARM may have a concern as well.  I don't know the
>> situation for x86 either.
>
> From cauldron I have a note that we need to look at the vectorizer cost model
> for both the ARM and AArch64 backends and move away from
> the set of magic constants that it currently returns.

Indeed.

> On AArch32, all the reduc_ patterns are emulated with pair-wise operations
> while on AArch64 they aren't. Thus they aren't likely to be the same cost as a
> standard vector arithmetic instruction. What difference this makes in practice
> remains to be seen, however the first step is moving towards the newer vectorizer
> cost model interface.
>
> I'll put this on a list of things for us to look at but I'm not sure who/when
> will get around to looking at this.

Note that the target should be able to "see" the cond reduction via the
add_stmt_cost hook calls.  It should see 'where' as the epilogue and
'kind' as a hint - recording stmt_info which should have sufficient info
for a good guess.  At finish_cost () time the target can compute a proper
overall cost.

Yes, the vectorizer "IL" (the stmt-infos) isn't very powerful and esp. for
code not corresponding to existing gimple stmts it doesn't even exist.
We need to improve in that area to better represent the desired transform.

Richard.

> regards
> Ramana

  reply	other threads:[~2015-09-15 11:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-10 15:11 Alan Hayward
2015-09-10 22:34 ` Bill Schmidt
2015-09-11  9:19   ` Alan Hayward
2015-09-11 13:23     ` Bill Schmidt
2015-09-11 13:55       ` Ramana Radhakrishnan
2015-09-11 14:41         ` Richard Sandiford
2015-09-11 15:14           ` Bill Schmidt
2015-09-11 15:30             ` Richard Sandiford
2015-09-11 15:50               ` Bill Schmidt
2015-09-11 16:54                 ` Ramana Radhakrishnan
2015-09-15 11:47                   ` Richard Biener [this message]
2015-09-14  9:50       ` Alan Lawrence
2015-09-14 14:20         ` Bill Schmidt
2015-09-15 12:10 ` Richard Biener
2015-09-15 15:41   ` Alan Hayward
2015-09-18 12:22     ` Richard Biener
2015-09-18 13:36       ` Alan Lawrence
2015-09-18 14:14         ` Alan Hayward
     [not found]         ` <D221D55E.8386%alan.hayward@arm.com>
2015-09-23 16:07           ` Alan Hayward
2015-09-30 12:49             ` Richard Biener
2015-10-01 15:22               ` Alan Hayward
2015-09-15 12:12 ` Richard Biener
2015-10-19  8:34 Alan Hayward
2015-10-21 10:46 ` Richard Biener
2015-10-22 14:18 ` Alan Lawrence
2015-10-22 14:23   ` Alan Hayward

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='CAFiYyc009gsc=6a=X0X=B3G2mpnuS+hhUeh+888FVDT_kDovbQ@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=Alan.Hayward@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ramana.gcc@googlemail.com \
    --cc=ramana.radhakrishnan@foss.arm.com \
    --cc=richard.sandiford@arm.com \
    --cc=wschmidt@linux.vnet.ibm.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).