From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D7F5C3858D33; Mon, 4 Mar 2024 14:53:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D7F5C3858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1709564004; bh=wRFti7L7mvck1D9K2l/tyykIamIdZKft8T5q7mwGVf0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X3oXG8C2veD1+7KNHZxD0jc0G1FYRtHZcr9La4CXEKOj9wuatpIO3hk3o/TQaC+Kc 9xpIP1H4/DxIBA7vEiYolYXAoZizvXWirzli4D+gm0JYZ263s0Rv2pZObca5VB6H/k raGEbJonuDAE/gNfsnjiyvCPtjXh3/WwcEOhAOCI= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113632] Range info for a^CSTP2-1 could be improved in some cases Date: Mon, 04 Mar 2024 14:53:24 +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 X-Bugzilla-Severity: enhancement X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113632 Andrew Macleod changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com --- Comment #1 from Andrew Macleod --- (In reply to Andrew Pinski from comment #0) > Take: > ``` > void dummy(); > _Bool f(unsigned long a) > { > _Bool cmp =3D a > 8192; > if (cmp) goto then; else goto e; > then: > unsigned long t =3D __builtin_clzl(a); // [0,50]=20 > t^=3D63; // [13,63] > return t >=3D 13; > e: > dummy(); > return 0; > } > ``` >=20 > Currently after the t^=3D63; we get: > ``` > # RANGE [irange] int [1, 63] MASK 0x3f VALUE 0x0 > _7 =3D _1 ^ 63; > ``` >=20 > But this could/should be improved to [13,63]. >=20 > If we change to using minus instead: > ``` > t =3D 63 - t; > ``` >=20 > We get the better range and the comparison (t >=3D 13) is optimized away. > ``` > Folding statement: t_10 =3D 63 - t_9; > Global Exported: t_10 =3D [irange] long unsigned int [13, 63] MASK 0x3f V= ALUE > 0x0 > Not folded > ``` >=20 > Yes this should up in real code, see the LLVM issue for more information = on > that. I think the current implementation of "operator_bitwise_xor::wi_fold ()" in range-op.cc was simply ported from the original version we used in the old= VRP code. so it is neither multi-range awre, nor been enhanced. If you put a break point there, you'll see its getting: (gdb) p lh_lb.dump() [0], precision =3D 32 $1 =3D void (gdb) p lh_ub.dump() [0x32], precision =3D 32 $2 =3D void (gdb) p rh_ub.dump() [0x3f], precision =3D 32 $3 =3D void (gdb) p rh_lb.dump() [0x3f], precision =3D 32 $4 =3D void One could conceivable do something much better than the general masking stu= ff that goes on if rh_lb =3D=3D rh_ub. I suspect we could probably do a bette= r job in general, but have never looked at it. It also looks like we make some minor attempts with signed values in wi_optimize_signed_bitwise_op (), but again, I do not think anyone has tr= ied to make this code do anything new yet.=