From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id CB6D8385828D; Sun, 10 Mar 2024 18:05:06 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CB6D8385828D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1710093906;
	bh=d/DquMpZrRZfjKLpzX+MSyibIP54jeQkWLzawXFBHhU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=nI+W1FSbcv2glD1I2PlWDM+n2lVtsjaYq7KL85SOYjjsfiN17JtZcW6i0k7gXOEue
	 wh4A5KhvhZMi7BlDLRHjeKBGCEsrCsNlDXQkBBtCdjk2p03JMSXkrfdXY8amM/NxiV
	 xLi6sKbnJjjgYvspPhxGaMX0Sk9VAzqvXWf4cN4g=
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/110199] [12/13/14 Regression] Missing VRP
 transformation with MIN_EXPR and known relation
Date: Sun, 10 Mar 2024 18:05:04 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: missed-optimization, needs-bisection
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: law at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110199-4-EkA9oglqVf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110199-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110199-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:

https://gcc.gnu.org/g:8fe27ed193d60f6cd8b34761858a720c95eabbdb

commit r14-9419-g8fe27ed193d60f6cd8b34761858a720c95eabbdb
Author: jlaw <jeffreyalaw@gmail.com>
Date:   Sun Mar 10 11:58:00 2024 -0600

    [committed] [PR tree-optimization/110199] Simplify MIN/MAX more often

    So as I mentioned in the BZ, the case of

    t =3D MIN_EXPR (A, B)

    where we know something about the relationship between A and B can be
trivially
    handled by some existing code in DOM.  That existing code would simplify
when A
    =3D=3D B.  But by testing GE and LE instead of EQ we can cover more cas=
es with
    minimal effort.  When applicable the MIN/MAX turns into a simple copy.

    I made one other change.  We have other binary operations that we simpl=
ify
when
    we know something about the relationship between the operands.  That co=
de
was
    not canonicalizing the order of operands when building the expression to
lookup
    in the hash tables to discover that relationship.  Since those paths are
only
    testing for equality, we can trivially reverse them and not have to wor=
ry
about
    changing codes or anything like that.  So extremely safe and avoids hav=
ing
to
    come back and fix that code to match the MIN_EXPR/MAX_EXPR case later.

    Bootstrapped on x86 and also tested on the crosses.  I briefly thought
there
    was an sh regression, but that was actually the recent fwprop changes
twiddling
    code generation for one test.

            PR tree-optimization/110199
    gcc/
            * tree-ssa-scopedtables.cc
            (avail_exprs_stack::simplify_binary_operation): Generalize hand=
ling
            of MIN_EXPR/MAX_EXPR to allow additional simplifications.=20
Canonicalize
            comparison operands for other cases.

    gcc/testsuite

            * gcc.dg/tree-ssa/minmax-27.c: New test.
            * gcc.dg/tree-ssa/minmax-28.c: New test.=