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

Reply via email to