This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> +@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.
(2) result_type != return_type
(3) Missing articles before "comparison operation", "input vectors".

> +  /* 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.

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.


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]