Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

[Richard Sandiford <richard.sandiford@arm.com>]

Robin Dapp <rdapp.gcc@gmail.com> writes:
>> It'd be good to expand on this comment a bit.  What kind of COND are you
>> anticipating?  A COND with the neutral op as the else value, so that the
>> PLUS_EXPR (or whatever) can remain unconditional?  If so, it would be
>> good to sketch briefly how that happens, and why it's better than using
>> the conditional PLUS_EXPR.
>> 
>> If that's the reason, perhaps we want a single-use check as well.
>> It's possible that OP1 is used elsewhere in the loop body, in a
>> context that would prefer a different else value.
>
> Would something like the following on top work?
>
> -  /* If possible try to create an IFN_COND_ADD instead of a COND_EXPR and
> -     a PLUS_EXPR.  Don't do this if the reduction def operand itself is
> +  /* If possible create a COND_OP instead of a COND_EXPR and an OP_EXPR.
> +     The COND_OP will have a neutral_op else value.
> +
> +     This allows re-using the mask directly in a masked reduction instead
> +     of creating a vector merge (or similar) and then an unmasked reduction.
> +
> +     Don't do this if the reduction def operand itself is
>       a vectorizable call as we can create a COND version of it directly.  */

It wasn't very clear, sorry, but it was the last sentence I was asking
for clarification on, not the other bits.  Why do we want to avoid
generating a COND_ADD when the operand is a vectorisable call?

Thanks,
Richard

>
>    if (ifn != IFN_LAST
>        && vectorized_internal_fn_supported_p (ifn, TREE_TYPE (lhs))
> -      && try_cond_op && !swap)
> +      && use_cond_op && !swap && has_single_use (op1))
>
> Regards
>  Robin