https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112994

--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>:

https://gcc.gnu.org/g:90c9403f89d3c55512ae83dd20e2023c2e4430f4

commit r14-6537-g90c9403f89d3c55512ae83dd20e2023c2e4430f4
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Thu Dec 14 11:55:49 2023 +0100

    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  <ja...@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.

Reply via email to