public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <bug-105136-4-jPCfcpdwIB@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-105136-4@http.gcc.gnu.org/bugzilla/>

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

--- 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 there 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=di
p92=si
...
p89=p92+p87 (dead p92)
p97=p91>>const (dead p91)
p83=flags?p87:p89 (dead p87, p89)
ax=p83

RA creates the following relations (to propagate assignment costs) for pseudos

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=1.

To get the right guaranteed solution we need some greedy algorithm which will
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 to do
this at this stage of gcc-12 release work.

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

  parent reply	other threads:[~2022-04-20 15:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-02 13:55 [Bug middle-end/105136] New: [11/12] " andre.schackier at gmail dot com
2022-04-04  7:19 ` [Bug target/105136] [11/12 regression] " rguenth at gcc dot gnu.org
2022-04-04  8:53 ` ubizjak at gmail dot com
2022-04-19 18:08 ` jakub at gcc dot gnu.org
2022-04-20 15:48 ` vmakarov at gcc dot gnu.org [this message]
2022-04-21  7:51 ` rguenth at gcc dot gnu.org
2023-05-29 10:06 ` [Bug target/105136] [11/12/13/14 " jakub at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-105136-4-jPCfcpdwIB@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).