Re: [RFC] Try vector<bool> as a new representation for vector masks

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Sep 18, 2015 at 3:40 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> 2015-09-18 15:22 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>> On Thu, Sep 3, 2015 at 3:57 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>> 2015-09-03 15:11 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>>> On Thu, Sep 3, 2015 at 2:03 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>>>> Adding CCs.
>>>>>
>>>>> 2015-09-03 15:03 GMT+03:00 Ilya Enkovich <enkovich.gnu@gmail.com>:
>>>>>> 2015-09-01 17:25 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>>>>>
>>>>>> Totally disabling old style vector comparison and bool pattern is a
>>>>>> goal but doing hat would mean a lot of regressions for many targets.
>>>>>> Do you want to it to be tried to estimate amount of changes required
>>>>>> and reveal possible issues? What would be integration plan for these
>>>>>> changes? Do you want to just introduce new vector<bool> in GIMPLE
>>>>>> disabling bool patterns and then resolving vectorization regression on
>>>>>> all targets or allow them live together with following target switch
>>>>>> one by one from bool patterns with finally removing them? Not all
>>>>>> targets are likely to be adopted fast I suppose.
>>>>
>>>> Well, the frontends already create vec_cond exprs I believe.  So for
>>>> bool patterns the vectorizer would have to do the same, but the
>>>> comparison result in there would still use vec<bool>.  Thus the scalar
>>>>
>>>>  _Bool a = b < c;
>>>>  _Bool c = a || d;
>>>>  if (c)
>>>>
>>>> would become
>>>>
>>>>  vec<int> a = VEC_COND <a < b ? -1 : 0>;
>>>>  vec<int> c = a | d;
>>>
>>> This should be identical to
>>>
>>> vec<_Bool> a = a < b;
>>> vec<_Bool> c = a | d;
>>>
>>> where vec<_Bool> has VxSI mode. And we should prefer it in case target
>>> supports vector comparison into vec<bool>, right?
>>>
>>>>
>>>> when the target does not have vec<bool>s directly and otherwise
>>>> vec<boo> directly (dropping the VEC_COND).
>>>>
>>>> Just the vector comparison inside the VEC_COND would always
>>>> have vec<bool> type.
>>>
>>> I don't really understand what you mean by 'doesn't have vec<bool>s
>>> dirrectly' here. Currently I have a hook to ask for a vec<bool> mode
>>> and assume target doesn't support it in case it returns VOIDmode. But
>>> in such case I have no mode to use for vec<bool> inside VEC_COND
>>> either.
>>
>> I was thinking about targets not supporting generating vec<bool>
>> (of whatever mode) from a comparison directly but only via
>> a COND_EXPR.
>
> Where may these direct comparisons come from? Vectorizer never
> generates unsupported statements. It means we get them from
> gimplifier?

That's what I say - the vecotirzer wouldn't generate them.

> So touch optabs in gimplifier to avoid direct comparisons?
> Actually vect lowering checks if we are able to make comparison and
> expand also uses vec_cond to expand vector comparison, so probably we
> may live with them.
>
>>
>>> In default implementation of the new target hook I always return
>>> integer vector mode (to have default behavior similar to the current
>>> one). It should allow me to use vec<bool> for conditions in all
>>> vec_cond. But we'd need some other trigger for bool patterns to apply.
>>> Probably check vec_cmp optab in check_bool_pattern and don't convert
>>> in case comparison is supported by target? Or control it via
>>> additional hook.
>>
>> Not sure if we are always talking about the same thing for
>> "bool patterns".  I'd remove bool patterns completely, IMHO
>> they are not necessary at all.
>
> I refer to transformations made by vect_recog_bool_pattern. Don't see
> how to remove them completely for targets not supporting comparison
> vectorization.

The vectorizer can vectorize comparisons by emitting a VEC_COND_EXPR
(the bool pattern would turn the comparison into a COND_EXPR).  I don't
see how the pattern intermediate step is necessary.  The important part
is to get the desired vector type of the comparison determined.

>>
>>>>
>>>> And the "bool patterns" I am talking about are those in
>>>> tree-vect-patterns.c, not any targets instruction patterns.
>>>
>>> I refer to them also. BTW bool patterns also pull comparison into
>>> vec_cond. Thus we cannot have SSA_NAME in vec_cond as a condition. I
>>> think with vector comparisons in place we should allow SSA_NAME as
>>> conditions in VEC_COND for better CSE. That should require new vcond
>>> optabs though.
>>
>> I think we do allow this, just the vectorizer doesn't expect it.  In the long
>> run I want to get rid of the GENERIC exprs in both COND_EXPR and
>> VEC_COND_EXPR.  Just didn't have the time to do this...
>
> That would be nice. As a first step I'd like to support optabs for
> VEC_COND_EXPR directly using vec<bool>.
>
> Thanks,
> Ilya
>
>>
>> Richard.
>>
>>> Ilya
>>>
>>>>
>>>> Richard.
>>>>
>>>>>>
>>>>>> Ilya