> I wonder how much if-then-else processing code would trip on the
> unexpected mode...
Yeah, it should rather be like
(if_then_else:V4SI
(vec_predicate:V4BI
>
> 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?
My mental model was always that a masked operation directly maps to an
operation on the active elements and then a merge of the inactive ones.
I'd think the proposed vec_predicate would be a superset of vec_merge
but I was hoping to introduce it without rewriting half of the x86 code ;)
vec_select's more advanced generic part/element selection and permutes would be
difficult to incorporate I think.
> Why two predicates? Can you explain?
Like an outer length predicate and a nested mask predicate each with specific
policy, basically nesting the whole insn:
(define_insn "*addv4si"
[(set (match_operand:V4SI 0 "register_operand" ...)
(if_then_else:V4BI
(vec_predicate
("register_or_immediate" # length)
(... # bias?)
( # "tail_policy"))
(if_then_else:V4BI
(vec_predicate
("register_or_immediate" # mask)
( # "mask_policy"))
(plus:V4SI
(match_operand 1)
(match_operand 2)...
sve and x86 would only have the inner mask-predicated insn. But I strongly
prefer no nesting.
--
Regards
Robin
