[RFC] Try vector<bool> as a new representation for vector masks
Fri Sep 18 12:29:00 GMT 2015
On Thu, Sep 3, 2015 at 3:57 PM, Ilya Enkovich <email@example.com> wrote:
> 2015-09-03 15:11 GMT+03:00 Richard Biener <firstname.lastname@example.org>:
>> On Thu, Sep 3, 2015 at 2:03 PM, Ilya Enkovich <email@example.com> wrote:
>>> Adding CCs.
>>> 2015-09-03 15:03 GMT+03:00 Ilya Enkovich <firstname.lastname@example.org>:
>>>> 2015-09-01 17:25 GMT+03:00 Richard Biener <email@example.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
I was thinking about targets not supporting generating vec<bool>
(of whatever mode) from a comparison directly but only via
> 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...
More information about the Gcc-patches