public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hubicka at kam dot mff.cuni.cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
Date: Fri, 19 Nov 2021 21:12:25 +0000	[thread overview]
Message-ID: <bug-103227-4-AkBE9Ft2JI@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-103227-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from hubicka at kam dot mff.cuni.cz ---
> I like the idea of transformation phases better than putting
> everything into tree-inline (and by extension ipa-param-manipulation)
> but perhaps we have to do aggregate constant replacements there too?

So the situation is that we inline call A->B (where both A and B are
clones of the main function) and while we place uses of the constant
parmater in A we miss replacement in B because transform is not run on
it.

I think proper solution here (discussed also few years ago) is to keep
the optimization summaries and teach value numbering to look up the
constant from the summary.

We also have other situations where the existing transform pass fails to
pattern match and this lets us to feed other info, like value ranges to
the optimizer.

We have open PR somwhere for this problem, right?

  parent reply	other threads:[~2021-11-19 21:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-13 21:05 [Bug tree-optimization/103227] New: 58% exchange2 regression with -Ofast -march=native on zen3 between g:1ae8edf5f73ca5c3 and g:2af63f0f53a12a72 hubicka at gcc dot gnu.org
2021-11-13 22:00 ` [Bug ipa/103227] " hubicka at gcc dot gnu.org
2021-11-13 22:11 ` hubicka at gcc dot gnu.org
2021-11-13 22:15 ` hubicka at gcc dot gnu.org
2021-11-15  9:04 ` [Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e rguenth at gcc dot gnu.org
2021-11-19 18:18 ` jamborm at gcc dot gnu.org
2021-11-19 21:12 ` hubicka at kam dot mff.cuni.cz [this message]
2021-11-19 21:22 ` hubicka at gcc dot gnu.org
2021-11-19 23:21 ` jamborm at gcc dot gnu.org
2021-11-20 12:32 ` hubicka at kam dot mff.cuni.cz
2021-11-20 12:39 ` hubicka at kam dot mff.cuni.cz
2021-11-21 15:16 ` cvs-commit at gcc dot gnu.org
2021-11-23 17:02 ` jamborm at gcc dot gnu.org
2021-11-24 12:52 ` jamborm at gcc dot gnu.org
2021-11-25 17:17 ` cvs-commit at gcc dot gnu.org
2021-11-26  9:19 ` hubicka at gcc dot gnu.org
2021-11-28 18:56 ` hubicka at gcc dot gnu.org
2022-12-14  0:04 ` cvs-commit at gcc dot gnu.org
2023-08-15 15:45 ` jamborm 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-103227-4-AkBE9Ft2JI@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).