public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-4825] Make -fwhole-program to work with incremental LTO linking Date: Wed, 21 Dec 2022 11:42:04 +0000 (GMT) [thread overview] Message-ID: <20221221114204.AB6EF3858D1E@sourceware.org> (raw) https://gcc.gnu.org/g:39ebd3a9f5cb8555bcb0422086e646ce833028a4 commit r13-4825-g39ebd3a9f5cb8555bcb0422086e646ce833028a4 Author: Jan Hubicka <jh@suse.cz> Date: Wed Dec 21 12:41:25 2022 +0100 Make -fwhole-program to work with incremental LTO linking Update documentation of -fwhole-program which was wrongly claiming that it is useless with LTO whole it is useful for LTO without plugin and extends -fwhole-program to also work with incremental linking. This is useful when building kernel where the incremental link is de-facto fina binary and only some explicitly marked symbols needs to remain. Bootstrapped/regtested x86_64-linux, comitted. gcc/ChangeLog: 2022-12-21 Jan Hubicka <hubicka@ucw.cz> * doc/invoke.texi: Fix documentation of -fwhole-program with LTO and document behaviour for incremental linking. gcc/lto/ChangeLog: 2022-12-21 Jan Hubicka <hubicka@ucw.cz> * lto-common.cc (lto_resolution_read): With incremental linking and whole program ignore turn LDPR_PREVAILING_DEF_IRONLY to LDPR_PREVAILING_DEF_IRONLY_EXP * lto-lang.cc (lto_post_options): Do not clear flag_whole_program for incremental link Diff: --- gcc/doc/invoke.texi | 9 ++++++--- gcc/lto/lto-common.cc | 11 +++++++++++ gcc/lto/lto-lang.cc | 1 - 3 files changed, 17 insertions(+), 4 deletions(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index d8a20797603..da9ad1068fb 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13719,9 +13719,12 @@ compiled. All public functions and variables with the exception of @code{main} and those merged by attribute @code{externally_visible} become static functions and in effect are optimized more aggressively by interprocedural optimizers. -This option should not be used in combination with @option{-flto}. -Instead relying on a linker plugin should provide safer and more precise -information. +With @option{-flto} this option has a limited use. In most cases the +precise list of symbols used or exported from the binary is known the +resolution info passed to the link-time optimizer by the linker plugin. It is +still useful if no linker plugin is used or during incremental link step when +final code is produced (with @option{-flto} +@option{-flinker-output=nolto-rel}). @item -flto[=@var{n}] @opindex flto diff --git a/gcc/lto/lto-common.cc b/gcc/lto/lto-common.cc index f64309731fa..125064ba47e 100644 --- a/gcc/lto/lto-common.cc +++ b/gcc/lto/lto-common.cc @@ -2118,6 +2118,17 @@ lto_resolution_read (splay_tree file_ids, FILE *resolution, lto_file *file) if (strcmp (lto_resolution_str[j], r_str) == 0) { r = (enum ld_plugin_symbol_resolution) j; + /* Incremental linking together with -fwhole-program may seem + somewhat contradictionary (as the point of incremental linking + is to allow re-linking with more symbols later) but it is + used to build LTO kernel. We want to hide all symbols that + are not explicitely marked as exported and thus turn + LDPR_PREVAILING_DEF_IRONLY_EXP + to LDPR_PREVAILING_DEF_IRONLY. */ + if (flag_whole_program + && flag_incremental_link == INCREMENTAL_LINK_NOLTO + && r == LDPR_PREVAILING_DEF_IRONLY_EXP) + r = LDPR_PREVAILING_DEF_IRONLY; break; } } diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc index d36453ba25d..7018dfae4a5 100644 --- a/gcc/lto/lto-lang.cc +++ b/gcc/lto/lto-lang.cc @@ -901,7 +901,6 @@ lto_post_options (const char **pfilename ATTRIBUTE_UNUSED) break; case LTO_LINKER_OUTPUT_NOLTOREL: /* .o: incremental link producing asm */ - flag_whole_program = 0; flag_incremental_link = INCREMENTAL_LINK_NOLTO; break;
reply other threads:[~2022-12-21 11:42 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20221221114204.AB6EF3858D1E@sourceware.org \ --to=hubicka@gcc.gnu.org \ --cc=gcc-cvs@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).