public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Biener <richard.guenther@gmail.com>
Cc: "Qing Zhao" <qing.zhao@oracle.com>,
	"Martin Liška" <mliska@suse.cz>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone
Date: Fri, 7 Oct 2022 15:03:54 +0200	[thread overview]
Message-ID: <Y0AjuvnK0gQfEqZS@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAFiYyc13_qJXB6KQWBk6Yzi7T1CWUNrwXFZEQyYJSKF5YXH2-A@mail.gmail.com>

> > WPA is Whole Program Analysis?
> 
> Yes.
> 
> > Okay, then  It will promote all static function to extern functions. That’s reasonable.
> 
> No, all extern functions to static functions.
> 
> > Is it hard to preserve the original “static” visibility in the IR?
> 
> Probably not hard, and the IPA pass adjusting visbility could as well
> mark the functions
> as not to be inlined with -flive-patching=inline-only-static.
> 
> > >
> > > OTOH inline-only-static could disable WPA inlining and do all inlining early ...
> >
> > Inline-only-static ONLY inlines static functions, how can it disable WPA inlining? Don’t quite understand here.
> 
> it's a flag so it can be used to control other things

GCC has two inliners
 1) ealry inlininer which happens at compile time and is quite
 restricted only to obvious cases (always_inline, flatten and very small
 functions)
 2) IPA inlining happening at link-time (WPA) which is using greedy
 algorithm and makes more complicated code size/speed tradeoffs
Indeed betwen 1 and 2 previously global functions may become static by
resolution info (they won't currently with kernel since we do
incremental linking).  We could easily keep track of originally static
functions and promoted to static functions and make IPA inlining to
honnor the patch.

I however wonder how much LTO optimization would remain. If we disable
all inter-module inlining and with live patching we also disable most of
other optimization, I think basically only unreachable code removal will
remain and possibly some propagation of "coldness" across the code.

I can implement this incrementally.
Martin, if live patching is happy about some symbols being promoted
static, the patch is OK.
Honza

  reply	other threads:[~2022-10-07 13:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-05 11:41 Martin Liška
2022-10-05 14:50 ` Qing Zhao
2022-10-05 17:36   ` Martin Liška
2022-10-05 18:18     ` Qing Zhao
2022-10-06  8:29       ` Richard Biener
2022-10-06  8:40         ` Martin Liška
2022-10-06 13:18         ` Qing Zhao
2022-10-07  6:34           ` Richard Biener
2022-10-07 13:03             ` Jan Hubicka [this message]
2022-10-07 14:30               ` Qing Zhao
2022-10-07 14:43                 ` Jan Hubicka
2022-10-07 15:36                   ` Qing Zhao
2022-10-07 13:04             ` Qing Zhao
2022-10-07 13:50               ` Martin Liška

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=Y0AjuvnK0gQfEqZS@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mliska@suse.cz \
    --cc=qing.zhao@oracle.com \
    --cc=richard.guenther@gmail.com \
    /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).