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
next prev parent 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).