From: Richard Biener <richard.guenther@gmail.com>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Cc: richard.sandiford@arm.com
Subject: Re: Remove redundant AND from count reduction loop
Date: Fri, 26 Jun 2015 09:59:00 -0000 [thread overview]
Message-ID: <CAFiYyc1xW8gaesQy-wbjEuPzOSC040RNTnRsVQYnNqh9eeBoLg@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1506260034030.2175@laptop-mg.saclay.inria.fr>
On Fri, Jun 26, 2015 at 12:39 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Wed, 24 Jun 2015, Richard Biener wrote:
>
>> On Wed, Jun 24, 2015 at 11:57 AM, Richard Sandiford
>> <richard.sandiford@arm.com> wrote:
>>>
>>> Richard Biener <richard.guenther@gmail.com> writes:
>>>>
>>>> On Tue, Jun 23, 2015 at 11:27 PM, Marc Glisse <marc.glisse@inria.fr>
>>>> wrote:
>>>>>
>>>>> On Tue, 23 Jun 2015, Richard Sandiford wrote:
>>>>>
>>>>>> +/* Vector comparisons are defined to produce all-one or all-zero
>>>>>> results.
>>>>>> */
>>>>>> +(simplify
>>>>>> + (vec_cond @0 integer_all_onesp@1 integer_zerop@2)
>>>>>> + (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
>>>>>> + (convert @0)))
>>>>>
>>>>>
>>>>>
>>>>> I am trying to understand why the test tree_nop_conversion_p is the
>>>>> right
>>>>> one (at least for the transformations not using VIEW_CONVERT_EXPR). By
>>>>> definition of VEC_COND_EXPR, type and TREE_TYPE (@0) are both integer
>>>>> vector
>>>>> types of the same size and number of elements. It thus seems like a
>>>>> conversion is always fine. For vectors, tree_nop_conversion_p
>>>>> apparently
>>>>> only checks that they have the same mode (quite often VOIDmode I
>>>>> guess).
>>>>
>>>>
>>>> The only conversion we seem to allow is changing the signed vector from
>>>> the comparison result to an unsigned vector (same number of elements
>>>> and same mode of the elements). That is, a check using
>>>> TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (@0)) would probably
>>>> be better (well, technically a TYPE_VECTOR_SUBPARTS && element
>>>> mode compare should be better as generic vectors might not have a vector
>>>> mode).
>>>
>>>
>>> OK. The reason I was being paranoid was that I couldn't see anywhere
>>> where we enforced that the vector condition in a VEC_COND had to have
>>> the same element width as the values being selected.
>>
>>
>> We don't require that indeed.
>>
>>> tree-cfg.c
>>> only checks that rhs2 and rhs3 are compatible with the result.
>>> There doesn't seem to be any checking of rhs1 vs. the other types.
>>> So I wasn't sure whether anything stopped us from, e.g., comparing two
>>> V4HIs and using the result to select between two V4SIs.
>>
>>
>> Nothing does (or should).
>
>
> The documentation patch you approved in
> https://gcc.gnu.org/ml/gcc-patches/2012-10/msg01109.html says something
> different. If it is really wrong, could you fix it?
Hmm, that simplifies things. It would be nice if these constraints
would also be
checked in the gimple verifier...
Richard.
> --
> Marc Glisse
next prev parent reply other threads:[~2015-06-26 9:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-23 15:42 Richard Sandiford
2015-06-23 21:36 ` Marc Glisse
2015-06-24 9:25 ` Richard Biener
2015-06-24 9:59 ` Richard Sandiford
2015-06-24 10:22 ` Richard Biener
2015-06-24 11:29 ` Richard Sandiford
2015-06-24 11:56 ` Richard Biener
2015-06-24 12:37 ` Richard Sandiford
2015-06-24 13:11 ` Richard Biener
2015-06-24 13:53 ` Richard Sandiford
2015-06-24 14:09 ` Richard Biener
2015-06-25 8:19 ` Richard Sandiford
2015-06-25 10:39 ` Richard Biener
2015-06-25 11:52 ` Richard Sandiford
2015-06-25 13:17 ` Richard Biener
2015-06-24 16:42 ` Jeff Law
2015-06-25 22:48 ` Marc Glisse
2015-06-26 9:59 ` Richard Biener [this message]
2015-06-28 14:09 ` Marc Glisse
2015-06-29 9:16 ` Richard Biener
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=CAFiYyc1xW8gaesQy-wbjEuPzOSC040RNTnRsVQYnNqh9eeBoLg@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.sandiford@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).