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 C277E3854803; Wed, 18 Nov 2020 14:55:44 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C277E3854803
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/85315] missed range optimisation opportunity
 for derefences where index must be 0 or otherwise constrained
Date: Wed, 18 Nov 2020 14:55:44 +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: 8.0.1
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat dot com
X-Bugzilla-Status: NEW
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: 
Message-ID: <bug-85315-4-0Ex3RMF3oS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-85315-4@http.gcc.gnu.org/bugzilla/>
References: <bug-85315-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: Wed, 18 Nov 2020 14:55:44 -0000

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

--- Comment #12 from Andrew Macleod <amacleod at redhat dot com> ---
Maybe I'm a little dense.

if we are presuming that=20=20
  &x + (a + b)=20
implies a + b =3D=3D 0, then we also should assume that

  &x + a  implies a =3D=3D 0

and if we can make those assumptions, then
&x + 1 is garbage because we can assume 1 =3D=3D 0.

And if a and b are both unsigned, then I guess we can also assume a =3D=3D =
b =3D=3D
MAX_UINT / 2 ?


Now, if we decided to actually do this...  I see IL:

<bb 2> :
  x.0_1 =3D x;
  y =3D x.0_1;
  a.1_2 =3D a;
  b.2_3 =3D b;
  _4 =3D a.1_2 + b.2_3;
  _5 =3D (long unsigned int) _4;
  _6 =3D _5 * 4;
  _7 =3D &y + _6;

The clear implications is that _6 =3D=3D 0 in this expression?

If we implemented that in the operator_pointer_plus::op1_range routine, and
then were to back substitute, we'd get
(_6)[0,0] =3D _5 * 4   -> _5 =3D [0,0]
(_5)[0,0] =3D (long unsigned int) _4;  -> _4 =3D=3D [0,0]
(_4)[0,0] =3D a.1_2 + b.2_3   which gives us nothing additional...  Other t=
han a
potential relationship to track I suppose  a.1_2 =3D=3D -B.2_3 for signed, =
but it
would record that _4 is [0,0] when we calculate an outgoing range.

but regardless, its seems that another straightforward place to do this wou=
ld
be in statement folding?  Isn't the basic assumption:

_7 =3D &y + _6;
implies _6 is always 0, which would enable us to fold this to
_7 =3D &y
then _6 is unused and the other statements would ultimately just go away.

So why not make folding simply throw away the "+ _6" part because it is now
being forced to be 0?  We can't really assume that it is [0,0], but then not
use that information to optimize?=