From: Richard Guenther <rguenther@suse.de>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: gcc-patches@gcc.gnu.org, dnovillo@redhat.com
Subject: Re: Allow more WHOPR partitions than souce files
Date: Sat, 04 Sep 2010 09:30:00 -0000 [thread overview]
Message-ID: <alpine.LNX.2.00.1009041055460.28912@zhemvz.fhfr.qr> (raw)
In-Reply-To: <20100903214239.GP1664@kam.mff.cuni.cz>
On Fri, 3 Sep 2010, Jan Hubicka wrote:
> Hi,
> this patch makes collect2 to accept more partition files then number of original .o files
> on the command line. This is needed for my partitioning patch that sometimes (for very
> large .o files) decide to break up single .o file into multiple.
>
> Bootstrapped/regtested x86_64-linux, OK?
Ick. Somebody ought to replace these arg arrays with a sane
datastructure when we're doing this kind of funny stuff.
Can you give that a try please? You might need to enhance
VEC_splice to allow splicing in the middle of a vector.
Thanks,
Richard.
> Honza
>
> * collect2.c (maybe_run_lto_and_relink): Allow number of partition files
> to exceed number of files.
> Index: collect2.c
> ===================================================================
> --- collect2.c (revision 163809)
> +++ collect2.c (working copy)
> @@ -942,12 +942,15 @@ maybe_run_lto_and_relink (char **lto_ld_
> {
> char **lto_c_argv;
> const char **lto_c_ptr;
> - const char **p, **q, **r;
> + const char **p, **q, **r, **last_entry = NULL;
> const char **lto_o_ptr;
> struct lto_object *list;
> char *lto_wrapper = getenv ("COLLECT_LTO_WRAPPER");
> struct pex_obj *pex;
> const char *prog = "lto-wrapper";
> + int lto_ld_argv_size = 0;
> + char **out_lto_ld_argv;
> + size_t num_files;
>
> if (!lto_wrapper)
> fatal ("COLLECT_LTO_WRAPPER must be set.");
> @@ -973,7 +976,7 @@ maybe_run_lto_and_relink (char **lto_ld_
> {
> int c;
> FILE *stream;
> - size_t i, num_files;
> + size_t i;
> char *start, *end;
>
> stream = pex_read_output (pex, 0);
> @@ -1007,10 +1010,14 @@ maybe_run_lto_and_relink (char **lto_ld_
> do_wait (prog, pex);
> pex = NULL;
>
> + for (lto_ld_argv_size = 0; lto_ld_argv[lto_ld_argv_size]; lto_ld_argv_size++)
> + ;
> + out_lto_ld_argv = XCNEWVEC(char *, num_files + lto_ld_argv_size + 1);
> + memcpy (out_lto_ld_argv, lto_ld_argv, sizeof (char *) * lto_ld_argv_size);
> /* After running the LTO back end, we will relink, substituting
> the LTO output for the object files that we submitted to the
> LTO. Here, we modify the linker command line for the relink. */
> - p = CONST_CAST2 (const char **, char **, lto_ld_argv);
> + p = CONST_CAST2 (const char **, char **, out_lto_ld_argv);
> lto_o_ptr = CONST_CAST2 (const char **, char **, lto_o_files);
>
> while (*p != NULL)
> @@ -1023,6 +1030,7 @@ maybe_run_lto_and_relink (char **lto_ld_
> if (*lto_o_ptr)
> {
> /* Replace first argument with LTO output file. */
> + last_entry = p;
> *p++ = *lto_o_ptr++;
> }
> else
> @@ -1047,15 +1055,27 @@ maybe_run_lto_and_relink (char **lto_ld_
> if (!list) ++p;
> }
>
> - /* The code above assumes we will never have more lto output files than
> - input files. Otherwise, we need to resize lto_ld_argv. Check this
> - assumption. */
> + /* Insert remaining .o files just after last file appearing in the argument
> + sequence. This way relative position of crtend and friends will be right. */
> if (*lto_o_ptr)
> - fatal ("too many lto output files");
> + {
> + size_t remaining_files = 0;
> + size_t tail_size = 0;
> +
> + for (p = lto_o_ptr; *p; p++)
> + remaining_files++;
> + for (p = last_entry + 1; *p; p++)
> + tail_size++;
> + memmove (last_entry + 1 + remaining_files,
> + last_entry + 1,
> + tail_size * sizeof (char *));
> + memcpy (last_entry + 1, lto_o_ptr, remaining_files * sizeof (char *));
> + }
>
> /* Run the linker again, this time replacing the object files
> optimized by the LTO with the temporary file generated by the LTO. */
> - fork_execute ("ld", lto_ld_argv);
> + fork_execute ("ld", out_lto_ld_argv);
> + free (lto_ld_argv);
>
> maybe_unlink_list (lto_o_files);
> }
>
>
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
next prev parent reply other threads:[~2010-09-04 8:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-03 22:58 Jan Hubicka
2010-09-04 9:30 ` Richard Guenther [this message]
2010-09-04 13:30 ` Jan Hubicka
2010-09-04 13:42 ` Richard Guenther
2010-09-09 0:52 ` Jan Hubicka
2010-09-09 9:00 ` Richard Guenther
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=alpine.LNX.2.00.1009041055460.28912@zhemvz.fhfr.qr \
--to=rguenther@suse.de \
--cc=dnovillo@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.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).