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

[Richard Biener <richard dot guenther at gmail dot 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.

> 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.

>>
>> 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...

Richard.

> Ilya
>
>>
>> Richard.
>>
>>>>
>>>> Ilya