Robin Dapp <rdapp....@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
