On Thu, 3 Jul 2025, Icen Zeyada wrote: > Merge simple_comparison patterns under a single vec_cond_expr for bit_and, > bit_ior, and bit_xor in the simplify pass. > > Ensure that when both operands of a bit_and, bit_or, or bit_xor are > simple_comparison > results, they reside within the same vec_cond_expr rather than separate ones. > This prepares the AST so that subsequent transformations (e.g., folding the > comparisons if possible) can take effect. > > PR tree-optimization/119196 > > gcc/ChangeLog: > > * match.pd: Merge multiple vec_cond_expr in a single one for > bit_and, bit_ior and bit_xor. > > Signed-off-by: Icen Zeyada <icen.zeya...@arm.com> > --- > gcc/match.pd | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/gcc/match.pd b/gcc/match.pd > index f4416d9172c..36317b9128f 100644 > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -5939,6 +5939,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > && !expand_vec_cond_expr_p (TREE_TYPE (@1), TREE_TYPE (@0))))) > (vec_cond @0 (op! @1 @3) (op! @2 @4)))) > > +/* (@0 ? @2 : @3) lop (@1 ? @2 : @3) --> (@0 lop @1) ? @2 : @3. */ > +(for lop (bit_and bit_ior bit_xor) > + (simplify > + (lop > + (vec_cond @0 integer_minus_onep@2 integer_zerop@3)
Why are you restricting this to integer_minus_onep/zerop? Is the assumption that such vec_cond is "cheap", thus we also do not need to add :s to them? > + (vec_cond @1 @2 @3)) > + (vec_cond (lop @0 @1) @2 @3))) So this turns a logical operation on the data type to a logical operation on the predicate type. You need to check this operation is supported by the target with target_supports_op_p (TREE_TYPE (@0), lop, optab_vector) I think the transform is sensible for arbitrary @2/@3 though in that case with :s on the vec_conds. Richard. > + > /* (c ? a : b) op d --> c ? (a op d) : (b op d) */ > (simplify > (op (vec_cond:s @0 @1 @2) @3) > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
