On Mon, Aug 19, 2024 at 01:55:38PM +0000, Tamar Christina wrote: > So would this not be the simplest fix: > > diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc > index 87b3dc413b8..fcbc83a49f0 100644 > --- a/gcc/tree-vect-patterns.cc > +++ b/gcc/tree-vect-patterns.cc > @@ -4558,6 +4558,9 @@ vect_recog_sat_add_pattern (vec_info *vinfo, > stmt_vec_info stmt_vinfo, > > if (gimple_unsigned_integer_sat_add (lhs, ops, NULL))
But then you call gimple_unsigned_integer_sat_add with mismatching types, not sure if that is ok. > { > + if (TREE_CODE (ops[1]) == INTEGER_CST) > + ops[1] = fold_convert (TREE_TYPE (ops[0]), ops[1]); > + This would be only ok if the conversion doesn't change the value of the constant. .ADD_OVERFLOW etc. could have e.g. int and unsigned arguments, you don't want to change the latter to the former if the value has the most significant bit set. Similarly, .ADD_OVERFLOW could have e.g. unsigned and unsigned __int128 arguments, you don't want to truncate the constant. So, you could e.g. do the fold_convert and then verify if wi::to_widest on the old and new tree are equal, or you could check for TREE_OVERFLOW if fold_convert honors that. As I said, for INTEGER_CST operands of .ADD/SUB/MUL_OVERFLOW, the infinite precision value (aka wi::to_widest) is all that matters. Jakub