> 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.
Conceptually I guess vec_merge comes closest, just that it currently only accepts a mask vector as condition and not a full-blown predicate. We could change that, though? That would still leave us with the slight semantic overload of having dedicated merge/blend instructions as well as using the vec_merge rtl expression as predicated instruction. > 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... I'd think a specific flag that indicates "never elide" for the vec_predicate could help for that case. I just wonder how to properly annotate the predicate. I'd be hesitant to add even more arguments/operand, even 5 as I proposed is not currently supported out of the box. Maybe an otherwise unused RTL flag can be repurposed? That might be too implicit, though? -- Regards Robin
