public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Ilya Enkovich <enkovich.gnu@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [vec-cmp, patch 1/6] Add optabs for vector comparison
Date: Thu, 22 Oct 2015 15:56:00 -0000	[thread overview]
Message-ID: <56290634.5020706@redhat.com> (raw)
In-Reply-To: <CAMbmDYZCEh6kXcYYzaXtKrKm25+VQEp9zfAa3aKOSE-P2L9k2g@mail.gmail.com>

On 10/22/2015 04:35 AM, Ilya Enkovich wrote:
> 2015-10-21 20:25 GMT+03:00 Jeff Law <law@redhat.com>:
>> On 10/08/2015 08:52 AM, Ilya Enkovich wrote:
>>>
>>> Hi,
>>>
>>> This series introduces autogeneration of vector comparison and its support
>>> on i386 target.  It lets comparison statements to be vectorized into vector
>>> comparison instead of VEC_COND_EXPR.  This allows to avoid some restrictions
>>> implied by boolean patterns.  This series applies on top of bolean vectors
>>> series [1].
>>>
>>> This patch introduces optabs for vector comparison.
>>>
>>> [1] https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00215.html
>>>
>>> Thanks,
>>> Ilya
>>> --
>>> gcc/
>>>
>>> 2015-10-08  Ilya Enkovich  <enkovich.gnu@gmail.com>
>>>
>>>          * expr.c (do_store_flag): Use expand_vec_cmp_expr for mask
>>> results.
>>>          * optabs-query.h (get_vec_cmp_icode): New.
>>>          * optabs-tree.c (expand_vec_cmp_expr_p): New.
>>>          * optabs-tree.h (expand_vec_cmp_expr_p): New.
>>>          * optabs.c (vector_compare_rtx): Add OPNO arg.
>>>          (expand_vec_cond_expr): Adjust to vector_compare_rtx change.
>>>          (expand_vec_cmp_expr): New.
>>>          * optabs.def (vec_cmp_optab): New.
>>>          (vec_cmpu_optab): New.
>>>          * optabs.h (expand_vec_cmp_expr): New.
>>>          * tree-vect-generic.c (expand_vector_comparison): Add vector
>>>          comparison optabs check.
>>>
>>>
>>> diff --git a/gcc/optabs-tree.c b/gcc/optabs-tree.c
>>> index 3b03338..aa863cf 100644
>>> --- a/gcc/optabs-tree.c
>>> +++ b/gcc/optabs-tree.c
>>> @@ -320,6 +320,19 @@ supportable_convert_operation (enum tree_code code,
>>>      return false;
>>>    }
>>>
>>> +/* Return TRUE if appropriate vector insn is available
>>> +   for vector comparison expr with vector type VALUE_TYPE
>>> +   and resulting mask with MASK_TYPE.  */
>>> +
>>> +bool
>>> +expand_vec_cmp_expr_p (tree value_type, tree mask_type)
>>> +{
>>> +  enum insn_code icode = get_vec_cmp_icode (TYPE_MODE (value_type),
>>> +                                           TYPE_MODE (mask_type),
>>> +                                           TYPE_UNSIGNED (value_type));
>>> +  return (icode != CODE_FOR_nothing);
>>> +}
>>> +
>>
>> Nothing inherently wrong with the code, but it seems like it's in the wrong
>> place.  Why optabs-tree rather than optabs-query?
>
> Because it uses tree type for arguments. There is no single tree usage
> in optabs-query.c. I think expand_vec_cond_expr_p is in optabs-tree
> for the same reason.
Note that expand_vec_cond_expr_p doesn't rely on enum insn code.  Well, 
it relies on enum insn code being an integer and CODE_FOR_nothing always 
having the value zero, which is probably worse.

We should clean both of these up so that:

   1. We don't need enum insn_code in optabs-tree
   2. We don't implicitly rely on CODE_FOR_nothing == 0

It may be as simple as a adding a predicate function to optabs-query 
that returns true/false if there's a suitable icode, then using that 
predicate in optabs-tree.

jeff


  reply	other threads:[~2015-10-22 15:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-08 14:52 Ilya Enkovich
2015-10-21 17:34 ` Jeff Law
2015-10-22 10:37   ` Ilya Enkovich
2015-10-22 15:56     ` Jeff Law [this message]
2015-10-22 16:21       ` Ilya Enkovich
2015-10-27 20:57         ` Jeff Law
2015-11-05 16:02           ` Ilya Enkovich
2015-11-06 16:15             ` Jeff Law

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=56290634.5020706@redhat.com \
    --to=law@redhat.com \
    --cc=enkovich.gnu@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).