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

--- Comment #12 from CVS 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:ffc7f200adbdf47f14b3594d9b21855c19cf797a

commit r12-6739-gffc7f200adbdf47f14b3594d9b21855c19cf797a
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Wed Jan 19 15:03:45 2022 +0100

    match.pd, optabs: Avoid vectorization of {FLOOR,CEIL,ROUND}_{DIV,MOD}_EXPR
[PR102860]

    power10 has modv4si3 expander and so vectorizes the following testcase
    where Fortran modulo is FLOOR_MOD_EXPR.
    optabs_for_tree_code indicates that the optab for all the *_MOD_EXPR
    variants is umod_optab or smod_optab, but that isn't true, that optab
    actually expands just TRUNC_MOD_EXPR.  For the other tree codes expmed.cc
    has code how to adjust the TRUNC_MOD_EXPR into those by emitting some
    extra comparisons and conditional updates.  Similarly for *_DIV_EXPR,
    except in that case it actually needs both division and modulo.

    While it would be possible to handle it in expmed.cc for vectors as well,
    we'd need to be sure all the vector operations we need for that are
    available, and furthermore we wouldn't account for that in the costing.

    So, IMHO it is better to stop pretending those non-truncating (and
    non-exact) div/mod operations have an optab.  For GCC 13, we should
    IMHO pattern match these in tree-vect-patterns.cc and transform them
    to truncating div/mod with follow-up adjustments and let the vectorizer
    vectorize that.  As written in the PR, for signed operands:
    r = x %[fl] y;
    is
    r = x % y; if (r && (x ^ y) < 0) r += y;
    and
    d = x /[fl] y;
    is
    r = x % y; d = x / y; if (r && (x ^ y) < 0) --d;
    and
    r = x %[cl] y;
    is
    r = x % y; if (r && (x ^ y) >= 0) r -= y;
    and
    d = /[cl] y;
    is
    r = x % y; d = x / y; if (r && (x ^ y) >= 0) ++d;
    (too lazy to figure out rounding div/mod now).  I'll create a PR
    for that.
    The patch also extends a match.pd optimization that floor_mod on
    unsigned operands is actually trunc_mod.

    2022-01-19  Jakub Jelinek  <ja...@redhat.com>

            PR middle-end/102860
            * match.pd (x %[fl] y -> x % y): New simplification for
            unsigned integral types.
            * optabs-tree.cc (optab_for_tree_code): Return unknown_optab
            for {CEIL,FLOOR,ROUND}_{DIV,MOD}_EXPR with VECTOR_TYPE.

            * gfortran.dg/pr102860.f90: New test.

Reply via email to