[Bug tree-optimization/88540] Issues with vectorization of min/max operations

[Bug tree-optimization/88540] Issues with vectorization of min/max operations

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |94864
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864
[Bug 94864] Failure to combine vunpckhpd+movsd into single vunpckhpd

[Bug tree-optimization/88540] Issues with vectorization of min/max operations

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> Also minmax_replacement in phi-opt could make
> use of the FMIN/FMAX IFNs when HONOR_NANS || HONOR_SIGNED_ZEROS
> and the direct IFN is available.

You should just need to teach match.pd rather than minmax_replacement to do
these days. I have patches that start to remove minmax_replacement even.

[Bug tree-optimization/88540] Issues with vectorization of min/max operations

[crazylht at gmail dot com]

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

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #6 from Hongtao.liu <crazylht at gmail dot com> ---
Note, x86 MINSS/MAXSS is not IEEE-conformant minimum and maximum operations, it
always return the second operand when there's NAN, but for fmin/fmax_optab it
should return the other operand.

[Bug tree-optimization/88540] Issues with vectorization of min/max operations

[crazylht at gmail dot com]

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

--- Comment #7 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #6)
> Note, x86 MINSS/MAXSS is not IEEE-conformant minimum and maximum operations,
> it always return the second operand when there's NAN, but for
> fmin/fmax_optab it should return the other operand.

But for this case, it shoud match MINSD d1[n], d2[n].
if d1[n] or d2[n] is NAN, it will always return d2[n](the second operand).
the conclusion also holds for sign-zeros, ieee take -0.0 equal as 0.0, which
means -0.0 < 0.0 should be false, then the second operand d2[n] should be
returned.

[Bug tree-optimization/88540] Issues with vectorization of min/max operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:9f8f37f5490076b10436993fb90d18092a960922

commit r14-2699-g9f8f37f5490076b10436993fb90d18092a960922
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Jul 13 08:58:58 2023 +0200

    tree-optimization/88540 - FP x > y ? x : y if-conversion without
-ffast-math

    The following makes sure that FP x > y ? x : y style max/min operations
    are if-converted at the GIMPLE level.  While we can neither match
    it to MAX_EXPR nor .FMAX as both have different semantics with IEEE
    than the ternary ?: operation we can make sure to maintain this form
    as a COND_EXPR so backends have the chance to match this to instructions
    their ISA offers.

    The patch does this in phiopt where we recognize min/max and instead
    of giving up when we have to honor NaNs we alter the generated code
    to a COND_EXPR.

    This resolves PR88540 and we can then SLP vectorize the min operation
    for its testcase.  It also resolves part of the regressions observed
    with the change matching bit-inserts of bit-field-refs to vec_perm.

    Expansion from a COND_EXPR rather than from compare-and-branch
    gcc.target/i386/pr54855-9.c by producing extra moves while the
    corresponding min/max operations are now already synthesized by
    RTL expansion, register selection isn't optimal.  This can be also
    provoked without this change by altering the operand order in the source.
    I have XFAILed that part of the test.

            PR tree-optimization/88540
            * tree-ssa-phiopt.cc (minmax_replacement): Do not give up
            with NaNs but handle the simple case by if-converting to a
            COND_EXPR.

            * gcc.target/i386/pr88540.c: New testcase.
            * gcc.target/i386/pr54855-9.c: XFAIL check for redundant moves.
            * gcc.target/i386/pr54855-12.c: Adjust.
            * gcc.target/i386/pr54855-13.c: Likewise.
            * gcc.target/i386/pr110170.c: Likewise.
            * gcc.dg/tree-ssa/split-path-12.c: Likewise.

[Bug tree-optimization/88540] Issues with vectorization of min/max operations

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Both issues are now fixed.

[Bug tree-optimization/88540] Issues with vectorization of min/max operations

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0