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 12A6D3857B82; Mon,  4 Jul 2022 06:38:09 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 12A6D3857B82
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/106164] (a > b) & (a >= b) does not get
 optimized until reassoc1
Date: Mon, 04 Jul 2022 06:38:09 +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: 12.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: pinskia at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106164-4-IzgbMYmz90@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106164-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106164-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jul 2022 06:38:09 -0000

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> This is the match.pd code:
> (for bitop (bit_and bit_ior)
>  (for cmp (tcc_comparison)
>   (for ocmp (tcc_comparison)
>    (for ncmp (tcc_comparison)
>     (simplify
>      (bitop (cmp:c @0 @1) (ocmp @0 @1))
>      (with {
> #if GIMPLE
> 	location_t loc =3D UNKNOWN_LOCATION;
> #endif
>         tree t =3D combine_comparisons (loc,
> 				      bitop =3D=3D BIT_IOR_EXPR
> 				       ? TRUTH_ORIF_EXPR : TRUTH_ANDIF_EXPR,
> 				      cmp, ocmp,
> 				      type, @0, @1);
>       }
>       (switch
>        (if (GENERIC && t)
> 	{t;})
>        (if (t && CONSTANT_CLASS_P (t))
> 	{t;})
>        (if (t && TREE_CODE (t) =3D=3D ncmp
> 	    /* Even though combine_comparisons should
> 	       return this, this is to double check. */
> 	    && operand_equal_p (TREE_OPERAND (t, 0), @0)
> 	    && operand_equal_p (TREE_OPERAND (t, 1), @1))
> 	(ncmp @0 @1)
>        )
>       )
>      )
>     )
>    )
>   )
>  )
> )
>=20
> I am not a fan of it though, I think we should change combine_comparisons=
 to
> return the comparison code or true/false or error out.
> The loc is due to combine_comparisons building the tree rather than match.
> The same is true of the whole checking of the result. I am going to test
> this fully and see if there is anything I need to change (there might be
> some testcases which need to be "improved").
>=20
> Also the whole ncmp for loop is still another issue which is a genmatch
> change to allow a non-name to be there but that is so so much harder to f=
ix
> and there is already a case like that too.

Yeah, allowing a "computed" code would be nice to support.  It shouldn't
be _too_ difficult.  Do another overload of id_base, like user_id, call it
sth like runtime_id - allow it only in replacement context and simply
replace with it's variable ID.  The only issue is that genmatch can do
almost no sanity checking on such cases, it would just need to be a
code_helper typed variable.=