On Tue, Feb 02, 2021 at 09:38:09AM +0000, Richard Sandiford wrote:
> > +/* In PROP_gimple_lvec mode, perform extra checking if RES_OP and return
> > + true if RES_OP is not appropriate - would require vector operations that
> > + would need to be lowered before expansion. */
> > +
> > +bool
> > +check_gimple_lvec (gimple_match_op *res_op)
>
> Guess this is personal preference, but the return value seems inverted.
> I'd have expected true if something is OK and false if something isn't.
Sure, I can change that.
> > + default:
> > + if (!VECTOR_MODE_P (mode))
> > + return true;
> > + op = optab_for_tree_code (code, type, optab_default);
> > + if (op == unknown_optab
> > + && code == NEGATE_EXPR
> > + && INTEGRAL_TYPE_P (TREE_TYPE (type)))
> > + op = optab_for_tree_code (MINUS_EXPR, type, optab_default);
> > + if (op && optab_handler (op, mode) != CODE_FOR_nothing)
> > + return false;
> > + return true;
>
> This doesn't look right for things like SVE comparisons, where the
> result is a VECTOR_BOOLEAN_TYPE_P with MODE_VECTOR_BOOL and where
> the inputs are something else. I guess it might also affect FP
> comparisons on most targets.
So how does that get through expand_vector_operations_1 ?
I don't see there anything that would catch it until:
if (compute_type == NULL_TREE)
compute_type = get_compute_type (code, op, type);
if (compute_type == type)
return;
and the above is an attempt to do what get_compute_type does.
expand_vector_comparison indeed has one case:
/* As seen in PR95830, we should not expand comparisons that are only
feeding a VEC_COND_EXPR statement. */
...
and if expand_vector_comparison returns NULL, nothing is lowered.
But we can't really look at immediate uses during the checking :(.
So do you suggest for now letting all comparisons get through?
Jakub
