On Tue, 8 Jul 2025, Icen Zeyada wrote: > > ________________________________ > 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.
Ah, of course it's invalid to turn (a ? 5 : 9) | (b ? 5 : 9) into (a | b) ? 5 : 9, it's just trivially valid for the minus-one/zero values. Sorry for the confusion. > > + (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? So adding the target check is all that's needed here. Thanks, 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) > -- 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)
