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 7019D3858409; Fri, 21 Jul 2023 16:28:11 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7019D3858409
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1689956891;
	bh=vmWVwbrDU0kXwfXmdpJEIKV0uG5WFBqTJ+UPJIftx90=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=KE6MK9OqEmomAXlBJefTsTVKnsUs0AwVgxuE8HqOWNpGWDIEhgdA7obdEllEr+/v2
	 hjM7f7qCp1qKASaFzpa62wxZ6B3e37XUJJRAjlpxTZYD22uk5kHlGWRS2nLwTx4ko8
	 2qwJp9BpHWPS7xajBU2+avrHv+YVxbwklFCzq73s=
From: "segher at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/110717] Double-word sign-extension
 missed-optimization
Date: Fri, 21 Jul 2023 16:28:10 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: segher at gcc dot gnu.org
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: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110717-4-hfQQE3UFPc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110717-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110717-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #13 from Segher Boessenkool <segher at gcc dot gnu.org> ---
So.  Before expand we have

  _6 =3D (__int128) x_3(D);
  x.0_1 =3D _6 << 59;
  _2 =3D x.0_1 >> 59;
  _4 =3D (__int128 unsigned) _2;
  return _4;

That should have been optimised better :-(

The RTL code it expands to sets the same pseudo multiple times.  Bad bad ba=
d.
This hampers many optimisations.  Like:
(insn 6 3 7 2 (set (reg:DI 124)
        (lshiftrt:DI (reg:DI 129 [ x+8 ])
            (const_int 5 [0x5]))) "110717.c":6:11 299 {lshrdi3}
     (nil))
(insn 7 6 8 2 (set (reg:DI 132)
        (ashift:DI (reg:DI 128 [ x ])
            (const_int 59 [0x3b]))) "110717.c":6:11 289 {ashldi3}
     (nil))
(insn 8 7 9 2 (set (reg:DI 132)
        (ior:DI (reg:DI 124)
            (reg:DI 132))) "110717.c":6:11 233 {*booldi3}
     (nil))
(They are subregs right after expand, totally unreadable; this is after
subreg1, slightly more readable, but essentially the same code still).

The web pass eventually gets rid of the double set in this case.

Because the shift-left-then-right survives all the way to combine, it (being
the greedy bastard that it is) will use the combiner patterns rs6000 has for
multi-precision shifts, before it would notice the two (multiprecision!)
shifts together are largely a no-op, so you get stuck at a local optimum.
Pat for the course for combine :-/=