>> > (define_insn "pred_add" >> > [(set (match_operand:V 0 "register_operand" "=vd") >> > (vec_predicate:V plus >> > [(match_operand:V 3 "register_operand" " v") >> > (match_operand:V 4 "register_operand" " v")] > > So there's not actually the predicated RTL operation, but just > the code and a vector of ... operands? I'd have expected either
Yeah I don't particularly like it either, in particular that we need to replicate canonicalization for these "unstructured" operands in simplify-rtx. It's not a big deal but feels redundant. > (vec_predicate > (plus:<mode> (...) (...)) This would still be my preferred way just by the way it reads and re-uses existing code. Richard's objection here was, though: > This again avoids contextual interpretation. A predicated plus is not > equivalent to taking an existing unpredicated plus and predicating it, > and vice versa. I didn't realize cond_exec is similar and that we need to avoid the "hoisting" situation already. So maybe the above wouldn't be too bad? Introducing a vec_pred_set would avoid a vec_copy... RTX code. I'm not looking forward to adding combine/etc. handling for vec_predicate + vec_pred_set combinations, though :) -- Regards Robin
