"Robin Dapp" <[email protected]> writes:
> Hi,
>
> Given the amount of boilerplate in our target code as well as some missed
> optimizations, I have been thinking about introducing a generic vector
> mask/predicate expression. My thinking was something similar to what we
> already have for RVV, but with a well-defined predicate:
>
> (define_insn "*addv4si"
> [(set (match_operand:V4SI 0 "register_operand" ...)
> (if_then_else:V4BI
> (vec_predicate
> ("register_or_immediate" # mask)
> ("register_or_immediate" # length)
> (... # bias?)
> ( # "mask_policy")
> ( # "tail_policy"))
> (plus:V4SI
> (match_operand 1)
> (match_operand 2))
> (match_operand 3) # merge/inactive elements operand
> ...))])
>
> For riscv mask_policy and tail_policy would be variable while all other
> targets have fixed policies. The policy determines how inactive elements
> are handled by the hardware (either unchanged or overwritten with -1 for
> riscv, unchanged or overwritten with 0 for all others AFAIK).
I like the idea of having a generic representation. However, I'd always
understood if_then_else to be a selection between two evaluated operands,
rather than a way of predicating operations. Thus:
(if_then_else:V4SF
...
(plus:V4SF x y)
...)
would do the addition on all lanes, regardless of the condition.
One problem we have for SVE is that a predicate is needed for some
operations even if the predicate is all-true. Using a generic
representation would tend to lead to the predicate and else value's
being optimised away. Any combine patterns that need the predicate
might therefore need a variant that matches the unpredicated form and
then uses a define_(insn_and_)split to add the predicate back in.
It would be nice to avoid that somehow...
Thanks,
Richard
