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 1E4DD3858C3A; Tue, 21 Sep 2021 20:09:04 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1E4DD3858C3A
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/102436] New: [11/12 Regression] Lost
 Load/Store Motion
Date: Tue, 21 Sep 2021 20:09:03 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at gcc dot gnu.org
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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
 attachments.created
Message-ID: <bug-102436-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: Tue, 21 Sep 2021 20:09:04 -0000

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

            Bug ID: 102436
           Summary: [11/12 Regression] Lost Load/Store Motion
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: law at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D51492&action=3Dedit
Testcase

So consider this loop (-O2, lim2 dump, trunk, x86_64):



;;   basic block 3, loop depth 1
;;    pred:       2
;;                10
  # target_8 =3D PHI <target_13(D)(2), target_17(10)>
  _4 =3D board[target_8];
  if (_4 =3D=3D 13)
    goto <bb 4>; [94.50%]
  else
    goto <bb 7>; [5.50%]
;;    succ:       4
;;                7

;;   basic block 4, loop depth 1
;;    pred:       3
  if (captures.32_5 =3D=3D 0)
    goto <bb 5>; [33.00%]
  else
    goto <bb 6>; [67.00%]
;;    succ:       5
;;                6

;;   basic block 5, loop depth 1
;;    pred:       4
  numb_moves.1_21 =3D numb_moves;
  _22 =3D (long unsigned int) numb_moves.1_21;
  _23 =3D _22 * 24;
  _24 =3D (struct move_s *) _23;
  _24->from =3D gfrom.30_1;
  _24->target =3D target_8;
  _24->captured =3D 13;
  _24->castled =3D 0;
  _24->promoted =3D 0;
  _24->ep =3D 0;
  _26 =3D numb_moves.1_21 + 1;
  numb_moves =3D _26;
;;    succ:       6

;;   basic block 6, loop depth 1
;;    pred:       4
;;                5
  target_17 =3D target_8 + offset_14;
  _7 =3D board[target_17];
  if (_7 !=3D 0)
    goto <bb 10>; [94.50%]
  else
    goto <bb 9>; [5.50%]
;;    succ:       10
;;                9

;;   basic block 10, loop depth 1
;;    pred:       6
  goto <bb 3>; [100.00%]
;;    succ:       3

In particular note the load from and store to numb_moves in block #5 within=
 the
loop.  I don't immediately see an aliasing issue that would prevent LSM.  T=
he
bigger problem is control flow, obviously the load/store may not be execute=
d,
but I thought our LIM/LSM code handled that correctly.

If we look at gcc-10 we get something like this:


;;   basic block 3, loop depth 1
;;    pred:       2
;;                10
  # target_9 =3D PHI <target_14(D)(2), target_19(10)>
  # numb_moves_lsm.43_6 =3D PHI <numb_moves_lsm.43_34(2),
numb_moves_lsm.43_2(10)>
  # numb_moves_lsm_flag.44_20 =3D PHI <numb_moves_lsm_flag.44_35(2),
numb_moves_lsm_flag.44_18(10)>
  _4 =3D board[target_9];
  if (_4 =3D=3D 13)
    goto <bb 4>; [94.50%]
  else
    goto <bb 7>; [5.50%]
;;    succ:       4
;;                7

;;   basic block 4, loop depth 1
;;    pred:       3
  if (captures.32_5 =3D=3D 0)
    goto <bb 5>; [33.00%]
  else
    goto <bb 6>; [67.00%]
;;    succ:       5
;;                6

;;   basic block 5, loop depth 1
;;    pred:       4
  numb_moves.1_21 =3D numb_moves_lsm.43_6;
  _22 =3D (long unsigned int) numb_moves.1_21;
  _23 =3D _22 * 24;
  _24 =3D (struct move_s *) _23;
  _24->from =3D gfrom.30_1;
  _24->target =3D target_9;
  _24->captured =3D 13;
  _24->castled =3D 0;
  _24->promoted =3D 0;
  _24->ep =3D 0;
  _26 =3D numb_moves.1_21 + 1;
  numb_moves_lsm.43_37 =3D _26;
  numb_moves_lsm_flag.44_38 =3D 1;
;;    succ:       6

;;   basic block 6, loop depth 1
;;    pred:       4
;;                5
  # numb_moves_lsm.43_2 =3D PHI <numb_moves_lsm.43_6(4), numb_moves_lsm.43_=
37(5)>
  # numb_moves_lsm_flag.44_18 =3D PHI <numb_moves_lsm_flag.44_20(4),
numb_moves_lsm_flag.44_38(5)>
  target_19 =3D target_9 + offset_15;
  _8 =3D board[target_19];
  if (_8 !=3D 0)
    goto <bb 10>; [94.50%]
  else
    goto <bb 11>; [5.50%]
;;    succ:       10
;;                11

[ ... ]
;;   basic block 10, loop depth 1
;;    pred:       6
  goto <bb 3>; [100.00%]
;;    succ:       3


Obviously with the load before the loop and the store after.=