When investigate the vectorization of .SAT_ADD, we notice there
are additional 2 forms, aka form 7 and 8 for .SAT_ADD.
Form 7:
#define DEF_SAT_U_ADD_FMT_7(T) \
T __attribute__((noinline)) \
sat_u_add_##T##_fmt_7 (T x, T y) \
{ \
return x > (T)(x + y) ? -1 : (x + y); \
}
Form 8:
#define DEF_SAT_U_ADD_FMT_8(T) \
T __attribute__((noinline)) \
sat_u_add_##T##_fmt_8 (T x, T y) \
{ \
return x <= (T)(x + y) ? (x + y) : -1; \
}
Thus, add above 2 forms to the match gimple_unsigned_integer_sat_add,
and then the vectorizer can try to recog the pattern like form 7 and
form 8.
The below test suites are passed for this patch:
1. The rv64gcv fully regression test with newlib.
2. The rv64gcv build with glibc.
3. The x86 bootstrap test.
4. The x86 fully regression test.
gcc/ChangeLog:
* match.pd: Add form 7 and 8 for the unsigned .SAT_ADD match.
Signed-off-by: Pan Li <pan2.li@intel.com>
(cond^ (ne (imagpart (IFN_ADD_OVERFLOW:c @0 @1)) integer_zerop)
integer_minus_onep (usadd_left_part_2 @0 @1)))
+/* Unsigned saturation add, case 7 (branch with le):
+ SAT_ADD = x <= (X + Y) ? (X + Y) : -1. */
+(match (unsigned_integer_sat_add @0 @1)
+ (cond^ (le @0 (usadd_left_part_1@2 @0 @1)) @2 integer_minus_onep))
+
+/* Unsigned saturation add, case 8 (branch with gt):
+ SAT_ADD = x > (X + Y) ? -1 : (X + Y). */
+(match (unsigned_integer_sat_add @0 @1)
+ (cond^ (gt @0 (usadd_left_part_1@2 @0 @1)) integer_minus_onep @2))
+
/* Unsigned saturation sub, case 1 (branch with gt):
SAT_U_SUB = X > Y ? X - Y : 0 */
(match (unsigned_integer_sat_sub @0 @1)