From: Jan Hubicka <hubicka@ucw.cz>
To: Michal Jires <mjires@suse.cz>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 2/7] lto: Remove random_seed from section name.
Date: Fri, 29 Dec 2023 22:17:42 +0100 [thread overview]
Message-ID: <ZY83dmirVZZ+bS4E@kam.mff.cuni.cz> (raw)
In-Reply-To: <1ab98391f1f12962c48d1dd4d7309fc219454c96.1700222403.git.mjires@suse.cz>
> Bootstrapped/regtested on x86_64-pc-linux-gnu
>
> gcc/ChangeLog:
>
> * lto-streamer.cc (lto_get_section_name): Remove random_seed in WPA.
This is also OK. (since it lacks explanation - the random suffixes are
added for ld -r to work. This never happens between WPA and ltrans, so
they only consume extra space and confuse the ltrans cache).
> ---
> gcc/lto-streamer.cc | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/lto-streamer.cc b/gcc/lto-streamer.cc
> index 4968fd13413..53275e32618 100644
> --- a/gcc/lto-streamer.cc
> +++ b/gcc/lto-streamer.cc
> @@ -132,11 +132,17 @@ lto_get_section_name (int section_type, const char *name,
> doesn't confuse the reader with merged sections.
>
> For options don't add a ID, the option reader cannot deal with them
> - and merging should be ok here. */
> + and merging should be ok here.
> +
> + WPA output is sent to LTRANS directly inside of lto-wrapper, so name
> + uniqueness for external tools is not needed.
> + Randomness would inhibit incremental LTO. */
> if (section_type == LTO_section_opts)
> strcpy (post, "");
> else if (f != NULL)
> sprintf (post, "." HOST_WIDE_INT_PRINT_HEX_PURE, f->id);
> + else if (flag_wpa)
> + strcpy (post, ".0");
Con't post be just empty string?
> else
> sprintf (post, "." HOST_WIDE_INT_PRINT_HEX_PURE, get_random_seed (false));
> char *res = concat (section_name_prefix, sep, add, post, NULL);
> --
> 2.42.1
>
next prev parent reply other threads:[~2023-12-29 21:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-17 20:16 [PATCH 0/7] lto: Incremental LTO Michal Jires
2023-11-17 20:16 ` [PATCH 1/7] lto: Skip flag OPT_fltrans_output_list_ Michal Jires
2023-12-29 21:16 ` Jan Hubicka
2023-11-17 20:16 ` [PATCH 2/7] lto: Remove random_seed from section name Michal Jires
2023-12-29 21:17 ` Jan Hubicka [this message]
2024-01-09 16:49 ` [PATCH 2/7 v2] " Michal Jires
[not found] ` <c480760c-f167-4e60-a27e-52bebdd1351b@suse.cz>
2024-05-14 11:28 ` Fwd: " Jan Hubicka
2023-11-17 20:17 ` [PATCH 3/7] Lockfile Michal Jires
2023-12-29 21:23 ` Jan Hubicka
2024-01-09 17:10 ` Michal Jires
2023-11-17 20:17 ` [PATCH 4/7] lto: Implement ltrans cache Michal Jires
2024-05-14 11:51 ` Jan Hubicka
2023-11-17 20:17 ` [PATCH 5/7] lto: Implement cache partitioning Michal Jires
2024-05-14 12:10 ` Jan Hubicka
2023-11-17 20:17 ` [PATCH 6/7] lto: squash order of symbols in partitions Michal Jires
2024-05-14 12:20 ` Jan Hubicka
2023-11-17 20:17 ` [PATCH 7/7] lto: partition specific lto_clone_numbers Michal Jires
2024-05-14 12:11 ` Jan Hubicka
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=ZY83dmirVZZ+bS4E@kam.mff.cuni.cz \
--to=hubicka@ucw.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=mjires@suse.cz \
/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).