> On 10 Oct 2024, at 09:03, Richard Biener <rguent...@suse.de> wrote: > > External email: Use caution opening links or attachments > > > On Wed, 9 Oct 2024, Jennifer Schmitz wrote: > >> >>> On 8 Oct 2024, at 10:31, Richard Biener <rguent...@suse.de> wrote: >>> >>> External email: Use caution opening links or attachments >>> >>> >>> On Fri, 4 Oct 2024, Jennifer Schmitz wrote: >>> >>>> As in https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663185.html, >>>> this patch guards the simplification x / y * y == x -> x % y == 0 in >>>> match.pd for vector types by a check for: >>>> 1) Support of the mod optab for vectors OR >>>> 2) Application before vector lowering for non-VL vectors. >>>> >>>> The patch was bootstrapped and tested with no regression on >>>> aarch64-linux-gnu and x86_64-linux-gnu. >>>> OK for mainline? >>> >>> - (if (TREE_CODE (TREE_TYPE (@0)) != COMPLEX_TYPE) >>> + (if (TREE_CODE (TREE_TYPE (@0)) != COMPLEX_TYPE >>> + || (VECTOR_INTEGER_TYPE_P (type) >>> + && ((optimize_vectors_before_lowering_p () >>> + && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST) >>> + || target_supports_op_p (type, TRUNC_MOD_EXPR, >>> + optab_vector)))) >>> >>> this looks a bit odd, VECTOR_INTEGER_TYPE_P (type) checks the >>> result type of the comparison. I think the whole condition is >>> better written as >>> >>> (if (TREE_CODE (TREE_TYPE (@0)) != COMPLEX_TYPE >>> && (!VECTOR_MODE_P (TYPE_MODE (TREE_TYPE (@0))) >>> || !target_supports_op_p (TREE_TYPE (@0), TRUNC_DIV_EXPR, >>> optab_vector) >>> || target_supports_op_p (TREE_TYPE (@0), TRUNC_MOD_EXPR, >>> optab_vector))) >>> >>> when we have non-vector mode we're before lowering, likewise when >>> the target doesn't support the division. Even before lowering >>> we shouldn't replace a supported division (and multiplication) >>> with an unsupported modulo. >> Dear Richard, >> thanks for the review. I updated the patch with your suggestion and >> re-validated on aarch64 and x86_64. >> Best, >> Jennifer >> >> This patch guards the simplification x / y * y == x -> x % y == 0 in >> match.pd by a check for: >> 1) Non-vector mode of x OR >> 2) Lack of support for vector division OR >> 3) Support of vector modulo >> >> The patch was bootstrapped and tested with no regression on >> aarch64-linux-gnu and x86_64-linux-gnu. >> OK for mainline? > > OK. Thanks, commited with a2e06b7f081a3d2e50e3afa8d3f1676a05099707. > > Thanks, > Richard. > >> Signed-off-by: Jennifer Schmitz <jschm...@nvidia.com> >> >> gcc/ >> PR tree-optimization/116831 >> * match.pd: Guard simplification to trunc_mod with check for >> mod optab support. >> >> gcc/testsuite/ >> PR tree-optimization/116831 >> * gcc.dg/torture/pr116831.c: New test. >> --- >> gcc/match.pd | 9 +++++++-- >> gcc/testsuite/gcc.dg/torture/pr116831.c | 10 ++++++++++ >> 2 files changed, 17 insertions(+), 2 deletions(-) >> create mode 100644 gcc/testsuite/gcc.dg/torture/pr116831.c >> >> diff --git a/gcc/match.pd b/gcc/match.pd >> index ba83f0f29e6..9b59b5c12f1 100644 >> --- a/gcc/match.pd >> +++ b/gcc/match.pd >> @@ -5380,8 +5380,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) >> /* x / y * y == x -> x % y == 0. */ >> (simplify >> (eq:c (mult:c (trunc_div:s @0 @1) @1) @0) >> - (if (TREE_CODE (TREE_TYPE (@0)) != COMPLEX_TYPE) >> - (eq (trunc_mod @0 @1) { build_zero_cst (TREE_TYPE (@0)); }))) >> + (if (TREE_CODE (TREE_TYPE (@0)) != COMPLEX_TYPE >> + && (!VECTOR_MODE_P (TYPE_MODE (TREE_TYPE (@0))) >> + || !target_supports_op_p (TREE_TYPE (@0), TRUNC_DIV_EXPR, >> + optab_vector) >> + || target_supports_op_p (TREE_TYPE (@0), TRUNC_MOD_EXPR, >> + optab_vector))) >> + (eq (trunc_mod @0 @1) { build_zero_cst (TREE_TYPE (@0)); }))) >> >> /* ((X /[ex] A) +- B) * A --> X +- A * B. */ >> (for op (plus minus) >> diff --git a/gcc/testsuite/gcc.dg/torture/pr116831.c >> b/gcc/testsuite/gcc.dg/torture/pr116831.c >> new file mode 100644 >> index 00000000000..92b2a130e69 >> --- /dev/null >> +++ b/gcc/testsuite/gcc.dg/torture/pr116831.c >> @@ -0,0 +1,10 @@ >> +/* { dg-additional-options "-mcpu=neoverse-v2" { target aarch64*-*-* } } */ >> + >> +long a; >> +int b, c; >> +void d (int e[][5], short f[][5][5][5]) >> +{ >> + for (short g; g; g += 4) >> + a = c ?: e[6][0] % b ? 0 : f[0][0][0][g]; >> +} >> + >> > > -- > 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)
smime.p7s
Description: S/MIME cryptographic signature
