On Mon, Jul 27, 2020 at 2:50 PM Martin Liška <mli...@suse.cz> wrote:
>
> On 7/27/20 1:22 PM, Richard Biener wrote:
> > I wonder what happens if we make vector lowering not allow the compare
> > expanded via expand_vec_cond_expr_p?
>
> So the following patch survives bootstrap and tests on x86_64-linux-gnu:
>
> diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
> index f8bd26f2156..fe6477c8592 100644
> --- a/gcc/tree-vect-generic.c
> +++ b/gcc/tree-vect-generic.c
> @@ -419,8 +419,7 @@ expand_vector_comparison (gimple_stmt_iterator *gsi, tree
> type, tree op0,
> return NULL_TREE;
>
> tree t;
> - if (!expand_vec_cmp_expr_p (TREE_TYPE (op0), type, code)
> - && !expand_vec_cond_expr_p (type, TREE_TYPE (op0), code))
> + if (!expand_vec_cmp_expr_p (TREE_TYPE (op0), type, code))
> {
> if (VECTOR_BOOLEAN_TYPE_P (type)
> && SCALAR_INT_MODE_P (TYPE_MODE (type))
>
> and provides a reasonable BIT_FIELD_REF expansion on the problematic s390x
> test-case.
> Is it a way to go?
If it avoids to do this expansion if the compare feeds supported
VEC_COND_EXPRs then
I think yes.
Richard.
>
> Martin
