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?
next prev 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: linkBe 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).