[RFC] [patch] Support vectorization of min/max location pattern

[Ira Rosen]

Richard Henderson <rth@redhat.com> wrote on 07/07/2010 11:42:55 PM:

> > +@hook TARGET_VECTORIZE_BUILTIN_VECT_COMPARE
> > +Target builtin that implements vector element-wise comparison.
> > +The value of @var{code} is one of the enumerators in @code{enum
> tree_code} and
> > +specifies comparison operation, @var{type} specifies the type of
> input vectors.
> > +The function returns the type of the comparison result in @var
> {result_type}.
> > +@end deftypefn
> ...
> > +/* Target builtin that implements vector element-wise comparison.  */
> > +DEFHOOK
> > +(builtin_vect_compare,
> > + "",
> > + tree, (unsigned code, tree type, tree *return_type), NULL)
>
> (1) The documentation should go into the DEFHOOK.

I am sorry, but I don't understand what you mean.

> (2) result_type != return_type
> (3) Missing articles before "comparison operation", "input vectors".

I'll fix that.

>
> > +  /* The min/max stmt must be x < y ? x : y.  */
>
> Why hasn't the cond_expr been simplified to min_expr already?
> Why does this need to be done inside the vectorizer?  This seems
> like a major conceptual problem to me.

I guess it happens because of location computation.

>
> What has BUILTIN_VECT_COMPARE really got to do with MIN/MAX?
> We support MIN/MAX_EXPR with vector arguments, don't we?  And we
> have direct support for min/max in optabs.  So I really don't see
> why you need to be fiddling with builtins at all.

BUILTIN_VECT_COMPARE is used for location and not for MIN/MAX. There are
two statements to vectorize: min/max and location computation. And min/max
is vectorized as you described. Location has different types in condition
(float) and then/else (integer).

Thanks,
Ira


>
>
> r~