match.pd: Simplify (t * u) / v -> t * (u / v) [PR112994]
commit90c9403f89d3c55512ae83dd20e2023c2e4430f4
authorJakub Jelinek <jakub@redhat.com>
Thu, 14 Dec 2023 10:55:49 +0000 (14 11:55 +0100)
committerJakub Jelinek <jakub@redhat.com>
Thu, 14 Dec 2023 10:55:49 +0000 (14 11:55 +0100)
tree2b7fa12d58519fcaa33b77431c7788ff88075b5d
parentcd794c3961017703a4d2ca0e854ea23b3d4b6373
match.pd: Simplify (t * u) / v -> t * (u / v) [PR112994]

The following testcase is optimized just on GENERIC (using
      strict_overflow_p = false;
      if (TREE_CODE (arg1) == INTEGER_CST
          && (tem = extract_muldiv (op0, arg1, code, NULL_TREE,
                                    &strict_overflow_p)) != 0)
        {
          if (strict_overflow_p)
            fold_overflow_warning (("assuming signed overflow does not occur "
                                    "when simplifying division"),
                                   WARN_STRICT_OVERFLOW_MISC);
          return fold_convert_loc (loc, type, tem);
        }
) but not on GIMPLE.

An earlier version of the patch regressed
+FAIL: gcc.dg/Wstrict-overflow-3.c correct warning (test for warnings, line 12)
test, we are indeed assuming that signed overflow does not occur
when simplifying division in there.

This version of the patch (which provides the simplification only
for GIMPLE) fixes that.
And/or we could add the
            fold_overflow_warning (("assuming signed overflow does not occur "
                                    "when simplifying division"),
                                   WARN_STRICT_OVERFLOW_MISC);
call into the simplification, but in that case IMHO it should go into
the (t * u) / u -> t simplification as well, there we assume the exact
same thing (of course, in both cases only in the spots where we don't
verify it through ranger that it never overflows).

Guarding the whole simplification to GIMPLE only IMHO makes sense because
the above mentioned folding does it for GENERIC (and extract_muldiv even
handles far more cases, dunno how many from that we should be doing on
GIMPLE in match.pd and what could be done elsewhere; e.g. extract_muldiv
can handle (x * 16 + y * 32) / 8 -> x * 2 + y * 4 etc.).

Dunno about the fold_overflow_warning, I always have doubts about why
such a warning is useful to users.

2023-12-14  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/112994
* match.pd ((t * 2) / 2 -> t): Adjust comment to use u instead of 2.
Punt without range checks if TYPE_OVERFLOW_SANITIZED.
((t * u) / v -> t * (u / v)): New simplification.

* gcc.dg/tree-ssa/pr112994-1.c: New test.
gcc/match.pd
gcc/testsuite/gcc.dg/tree-ssa/pr112994-1.c [new file with mode: 0644]