> Am 07.07.2024 um 11:26 schrieb Robin Dapp <rdapp....@gmail.com>:
>
>
>>
>> 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?
I think it’s less than ideal to only do this via match but I think we cannot do
without the match patterns if you think of unrolling and simplification
exposing the opportunities.
Richard
> 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.
