> 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.
