On Tue, 17 Feb 2026, Robin Dapp wrote:
> 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 don't think the tail policy is important for code-gen as we don't care
> about
> tail elements anyway in length-controlled loops. It helps riscv to include
> it,
> though ;) and would keep things orthogonal.
>
> That way, simplify-rtx and friends could reason about the predicate, identify
> dead statements, and possibly merge predicates. On top, combine, fwprop, and
> others are already prepared to handle if_then_else so changes there would
> hopefully be minimal.
>
> Another option would be to re-use vec_merge and enhance its predicate/mask
> but
> I don't think vec_merge handling is as pervasive as if_then_else. Besides, I
> don't like its operand order :)
I wonder how much if-then-else processing code would trip on the
unexpected mode...
What I do not like is that this if-then-else gets us a third way of
selecting lanes, apart from vec_merge and (vec_select (vec_concat ..)).
I was always hoping we can get rid of vec_merge and/or
(vec_select (vec_concat ..)) in favor of a single way to do permutes.
Your if-then-else can only do blends like vec_merge. Maybe that's
a fine thing, but then can we get rid of vec_merge?
> In general, things could be changed incrementally without breaking existing
> code. But I didn't want to start implementing a half-baked solution that
> others don't agree with.
>
> Comments, suggestions?
>
> We could also nest two predicates for riscv and keep it simpler for other
> targets?
Why two predicates? Can you explain?
Thanks,
Richard.
>
>
--
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
