Robin Dapp <rdapp....@gmail.com> writes:
>> FTR, my concern & suggestion was:
>>
>> I suppose the difficulty is that we might make:
>>
>> MASK_LOAD (mask, ptr, some-arbitrary-else-value)
>>
>> seem as cheap as:
>>
>> MASK_LOAD (mask, ptr, { 0, 0,. ... 0})
>>
>> which definitely isn't the case for SVE (and I'm guessing also
>> for AVX). It would be better to keep the:
>>
>> COND_EXPR (mask, ..., some-arbitrary-else-value)
>>
>> separate and try to optimise it with surrounding code.
>
> Ah, I rather understood that as an "either or" rather than an "and".
Yeah, could have been clearer, sorry.
>> That is, we'd add the else value to the maskload optab and MASK_LOAD
>> internal function, but use predicates to test whether a target supports
>> a particular else value.
>
> So e.g. for SVE we'd have
>
> res = MASK_LOAD (mask, ptr, {0, 0, ..., 0})
> COND_EXPR (mask, res, {0, 0, ...})
>
> which would always be folded/optimized away, while for RVV
> we'd have
>
> res = MASK_LOAD (mask, ptr, whatever_else_value)
> COND_EXPR (mask, res, {0, 0, ...})
>
> that could/should result in a separate instruction depending on
> the rest of the code?
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.
Thanks,
Richard
