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 880803858C27; Wed, 20 Apr 2022 15:48:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 880803858C27
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/105136] [11/12 regression] Missed optimization
 regression with 32-bit adds and shifts
Date: Wed, 20 Apr 2022 15:48:46 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: missed-optimization, ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vmakarov at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-105136-4-jPCfcpdwIB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-105136-4@http.gcc.gnu.org/bugzilla/>
References: <bug-105136-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, 20 Apr 2022 15:48:46 -0000

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

--- Comment #4 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
I am just saying trivial things here that RA is a NP-complete task and ther=
e is
no optimal solution for all tests.  For GCC it is even more complicated as =
RA
solves code selection tasks too.  Basically we have for this test

p91=3Ddi
p92=3Dsi
...
p89=3Dp92+p87 (dead p92)
p97=3Dp91>>const (dead p91)
p83=3Dflags?p87:p89 (dead p87, p89)
ax=3Dp83

RA creates the following relations (to propagate assignment costs) for pseu=
dos

p83(ax preferred)---p87---p91(di preferred)
\
 \------------------p89---p92(si preferred)

Only assignment ax for p89 can create the desired code.  Relation costs of
p87--p91 and p89--p92 or p83--p87 and p83--p89 are the same even if we use
--param ira-consider-dup-in-all-alts=3D1.

To get the right guaranteed solution we need some greedy algorithm which wi=
ll
take a lot of time to work and check results not only at the end of IRA but=
 at
the end LRA.

I can revert meaningful changes of the patch which resulted in this
degradation.  But as I can see this creates 3 new test failures for tests
avx512fp16-conjugation-1.c and avx512fp16vl-conjugation-1.c.  Also I can not
guarantee that such change will not result in more serious benchmark (e.g.
SPEC) degradation.

But in any I can try to do this.  Although I am not sure taht it is worth t=
o do
this at this stage of gcc-12 release work.

Richard and Jakub, what your thoughts about reverting my patch in question?=