From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 09D4C3858D28; Wed, 6 Jul 2022 22:05:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 09D4C3858D28 From: "already5chosen at yahoo dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/106220] New: x86-64 optimizer forgets about shrd peephole optimization pattern when faced with more than one in close proximity Date: Wed, 06 Jul 2022 22:05:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 12.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: already5chosen at yahoo 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2022 22:05:05 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106220 Bug ID: 106220 Summary: x86-64 optimizer forgets about shrd peephole optimization pattern when faced with more than one in close proximity Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: already5chosen at yahoo dot com Target Milestone: --- I am reporting about right shift issue, but left shift has the same issues = as well. In theory, gcc knows how to calculate lower 64 bits of the right shift of 128-bit number with a single instruction when it is provable that shift cou= nt is in range [0:63]. In practice, it does it only under very special conditi= on. See here: https://godbolt.org/z/fhdo8xhxW foo1to1 is good foo2to1 is good foo1to2 starts well but is broken near the end but hyperactive vectorizer. But that's a separate issue already reported in 105617. foo2to2, foo2to3, foo3to4 - looks like compiler forgot all it knew about double-word right shifts, or, more likely, forgot that (x % 64) is always in range [0:63]. I am reporting it as a target issue despite being sure that the problem is = not in the x86-64 back end itself, but somehow in interaction between various phases of optimizer. As 80+ percents of my reports. However it's your call, not mine. In practice, an impact is most visible on x86-64, because, due to existence of shrd instruction, x86-64 is potentially very good in this sort of tasks. On ARM64 or on POWER64LE the relative slow= down is lower, because an optimal code is not as fast. P.S 82261 sounds similar, but I am not sure it is related.=