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 8278C3858404; Wed, 29 Dec 2021 03:16:24 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8278C3858404
From: "zhaoweiliew at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/103855] Missed optimization: 64bit division
 used instead of 32bit division
Date: Wed, 29 Dec 2021 03:16: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: 12.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zhaoweiliew at gmail 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: 
Message-ID: <bug-103855-4-n6sGQZW5LV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-103855-4@http.gcc.gnu.org/bugzilla/>
References: <bug-103855-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, 29 Dec 2021 03:16:24 -0000

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

--- Comment #1 from Zhao Wei Liew <zhaoweiliew at gmail dot com> ---
After some research, I decided to look into value range propagation (VRP). I
compiled with `-fdump-tree-vrp` and the VRP files contained the following f=
or
`optimized()`:

For the file ending in .vrp1,

```
;; Function unoptimized (_Z11unoptimizedjj, funcdef_no=3D1, decl_uid=3D2121,
cgraph_uid=3D2, symbol_order=3D1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:

_1: long long unsigned int [0, 4294967295]
_2: long long unsigned int [0, 4294967295]
a_3(D): unsigned int VARYING
all_4: long long unsigned int [0, 4294967295]
b_5(D): unsigned int VARYING
_6: unsigned int VARYING


unsigned int unoptimized (unsigned int a, unsigned int b)
{
  long long unsigned int all;
  long long unsigned int _1;
  long long unsigned int _2;
  unsigned int _6;

  <bb 2> [local count: 1073741824]:
  all_4 =3D (long long unsigned int) a_3(D);
  _1 =3D (long long unsigned int) b_5(D);
  _2 =3D all_4 / _1;
  _6 =3D (unsigned int) _2;
  return _6;

}
```

and for the file ending in .vrp2,

```
;; Function unoptimized (_Z11unoptimizedjj, funcdef_no=3D1, decl_uid=3D2121,
cgraph_uid=3D2, symbol_order=3D1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
Exported global range table:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
_1  : long long unsigned int [0, 4294967295]
_2  : long long unsigned int [0, 4294967295]
all_4  : long long unsigned int [0, 4294967295]
unsigned int unoptimized (unsigned int a, unsigned int b)
{
  long long unsigned int all;
  long long unsigned int _1;
  long long unsigned int _2;
  unsigned int _6;

  <bb 2> [local count: 1073741824]:
  all_4 =3D (long long unsigned int) a_3(D);
  _1 =3D (long long unsigned int) b_5(D);
  _2 =3D all_4 / _1;
  _6 =3D (unsigned int) _2;
  return _6;

}
```

If I'm interpreting the above correctly, the optimizer seems to think all_4=
 can
be in the range [0, 4294967295], which is correct.

Hence, I suppose it's safe to conclude that VRP isn't the issue here? Please
correct me if I'm wrong.=