https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Jakub Jelinek from comment #5)
>
> > I'm not sure it is a good idea. Then expand_vec_cond_expr_p will return
> > true, vectorizer will use them heavily etc. and the expander will just find
> > out it can't
>
> How about teaching these predicates to handle FAIL from the expander? Then
> we
> can change expanders to (e.g. vcond<VI8F_128:mode>v2di):
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index fde520f..4cd3bb2 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -11086,10 +11086,11 @@
> (match_operand:V2DI 5 "general_operand")])
> (match_operand:VI8F_128 1)
> (match_operand:VI8F_128 2)))]
> - "TARGET_SSE4_2"
> + "TARGET_SSE4_1"
> {
> - bool ok = ix86_expand_int_vcond (operands);
> - gcc_assert (ok);
> + if (!ix86_expand_int_vcond (operands))
> + FAIL;
> +
> DONE;
> })
How would it expand? Repeat all the vector condition/comparison lowering code
from tree-vect-generic.c on RTL? Compared to that I think it would be simpler
to handle it in ix86_expand_int_vcond - if the only problematic mode is
V2DImode, then that might be easier than just writing code that would handle
arbitrary vectors. That still means the vectorizer believes all the
comparisons are supported and might result in really terrible code (rather than
just giving up).
