________________________________ From: Richard Biener <rguent...@suse.de> Sent: 08 July 2025 10:01 To: Icen Zeyada <icen.zeya...@arm.com> Cc: gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org>; jeffreya...@gmail.com <jeffreya...@gmail.com>; i...@airs.com <i...@airs.com>; Richard Earnshaw <richard.earns...@arm.com>; pins...@gmail.com <pins...@gmail.com>; Victor Do Nascimento <victor.donascime...@arm.com>; Tamar Christina <tamar.christ...@arm.com> Subject: Re: [PATCH v4 1/2] tree-simplify: unify simple_comparison ops in vec_cond for bit and/or/xor [PR119196]
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? >From my understanding the reason we specify those specific ones is that we >expect a vec_cond and therefore it can only be true or false which in this >case would be integer_minus_onep or integer_zerop. I believe those were the >values in the original tree when specifying whether an expression with a >vec_cond was true or not so when matching i just had those expressions in mind. > + (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. I am happy to add the target check but I am curious how generalising the @2 @3 would help with the current bug on bugzilla we were trying to solve? Or do you think this just might be better in the larger context? > + > /* (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)
