> Yeah, I think so. I guess for RVV there's a choice between: > > (1) making the insn predicate accept all else values and making > the insn emit an explicit blend between the loaded result > and the else value > > (2) making the insn predicate only accept “undefined” (SCRATCH in > rtl terms) > > (2) sounds more in keeping with Juzhe's fix for PR110751.
I think (2) is the reasonable choice for the future, however: I misinterpreted the RVV spec. The implementation has the choice between filling with ones or leaving unchanged (merging). So it's not really "anything" as I claimed before. This implies that we could defer to target_preferred_else_value and eventually, in the target, leave it to the uarch what to return (either "1" or "undefined"). On the general strategy: Should we (for SVE, AVX512 etc.) have a match pattern that folds res = MASK_LOAD (mask, ptr, {0, 0, ..., 0}) COND_EXPR (mask, res, {0, 0, ...}) into just MASK_LOAD then? MASK_LOAD (..., {0, 0, ..., 0}) would not be emitted for RVV and we'd need to fold the COND_EXPR differently, maybe with a combination of match patterns similar to the ones in my RFC as well as a separate "pass" for mask tracking as Richi suggested? Regards Robin p.s. We have the choice of different policies for length masking and element masking. I don't think the problem arose yet due to the way we handle length control in the vectorizer but I could imagine, at least in principle, the need for two separate else values for MASK_LEN.