public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).