Hi Pan,
>
> Thanks Jakub for explaining.
>
> Hi Richard,
>
> Does it mean we need to do some promotion similar as this patch to make the
> vectorizable_call happy
> when there is a constant operand? I am not sure if there is a better approach
> for
> this case.
I'll leave it up to Richi, but if I understand correctly it looks like this is
only a problem for constants because
unsigned_integer_sat_add in the constant case doesn't enforce the types be
equal, most likely specifically
so we can do the type coercions later?
But the constant is always operand2 in that case and you check that the result
type matched the first operand. So only operand2 can be in a different type.
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))
{
+ if (TREE_CODE (ops[1]) == INTEGER_CST)
+ ops[1] = fold_convert (TREE_TYPE (ops[0]), ops[1]);
+
gimple *stmt = vect_recog_build_binary_gimple_stmt (vinfo, stmt_vinfo,
IFN_SAT_ADD, type_out,
lhs, ops[0], ops[1]);
ps. You have the same problem at every usage site of unsigned_integer_sat_add
don't you?
So doesn't the scalar variant also introduce the mismatch? The one in
tree-ssa-math-opts.cc?
Thanks,
Tamar
>
> Pan
>
> -----Original Message-----
> From: Jakub Jelinek <ja...@redhat.com>
> Sent: Sunday, August 18, 2024 5:21 AM
> To: Li, Pan2 <pan2...@intel.com>
> Cc: Richard Biener <richard.guent...@gmail.com>; gcc-patches@gcc.gnu.org;
> juzhe.zh...@rivai.ai; kito.ch...@gmail.com; tamar.christ...@arm.com;
> jeffreya...@gmail.com; rdapp....@gmail.com; Liu, Hongtao
> <hongtao....@intel.com>
> Subject: Re: [PATCH v1] Vect: Promote unsigned .SAT_ADD constant operand for
> vectorizable_call
>
> On Sat, Aug 17, 2024 at 05:03:14AM +0000, Li, Pan2 wrote:
> > Thanks Richard for confirmation. Sorry almost forget this thread.
> >
> > Please feel free to let me know if there is anything I can do to fix this
> > issue.
> Thanks a lot.
>
> There is no bug. The operands of .{ADD,SUB,MUL}_OVERFLOW don't have to
> have the same type, as described in the
> __builtin_{add,sub,mul}_overflow{,_p} documentation, each argument can have
> different type and result yet another one, the behavior is then (as if) to
> perform the operation in infinite precision and if that result fits into
> the result type, there is no overflow, otherwise there is.
> So, there is no need to promote anything, promoted constants would have the
> same value as the non-promoted ones and the value is all that matters for
> constants.
>
> Jakub
