public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* Do not stream BINFO_VIRTUALs to ltrans unit
@ 2011-06-13 13:11 Jan Hubicka
  2011-06-14 10:14 ` Richard Guenther
  0 siblings, 1 reply; 2+ messages in thread
From: Jan Hubicka @ 2011-06-13 13:11 UTC (permalink / raw)
  To: gcc-patches

Hi,
by accident I noticed that BINFO_VIRTUALs streaming is really expensive. It
about doubles amount of IL and types streamed by Mozilla.

One obvious optimization is to not stream into ltrans unit where it is
too late to do any useful devirtualization anyway.
Doing so reduces /tmp usage from 1.7GB to 1.1GB and proportionaly reduces
streaming out time.

Bootstrapped/regtested x86_64-linux.
OK?
Honza
	* lto-streamer-out.c (lto_output_ts_binfo_tree_pointers): Do not
	stream BINFO_VIRTUALS to ltrans units.
Index: lto-streamer-out.c
===================================================================
--- lto-streamer-out.c	(revision 174985)
+++ lto-streamer-out.c	(working copy)
@@ -1117,7 +1117,11 @@
 
   lto_output_tree_or_ref (ob, BINFO_OFFSET (expr), ref_p);
   lto_output_tree_or_ref (ob, BINFO_VTABLE (expr), ref_p);
-  lto_output_tree_or_ref (ob, BINFO_VIRTUALS (expr), ref_p);
+  /* BINFO_VIRTUALS is used to drive type based devirtualizatoin.  It often links
+     together large portions of programs making it harder to partition.  Becuase
+     devirtualization is interesting before inlining, only, there is no real
+     need to ship it into ltrans partition.  */
+  lto_output_tree_or_ref (ob, flag_wpa ? NULL : BINFO_VIRTUALS (expr), ref_p);
   lto_output_tree_or_ref (ob, BINFO_VPTR_FIELD (expr), ref_p);
 
   output_uleb128 (ob, VEC_length (tree, BINFO_BASE_ACCESSES (expr)));

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Do not stream BINFO_VIRTUALs to ltrans unit
  2011-06-13 13:11 Do not stream BINFO_VIRTUALs to ltrans unit Jan Hubicka
@ 2011-06-14 10:14 ` Richard Guenther
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Guenther @ 2011-06-14 10:14 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: gcc-patches

On Mon, Jun 13, 2011 at 2:54 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> Hi,
> by accident I noticed that BINFO_VIRTUALs streaming is really expensive. It
> about doubles amount of IL and types streamed by Mozilla.
>
> One obvious optimization is to not stream into ltrans unit where it is
> too late to do any useful devirtualization anyway.
> Doing so reduces /tmp usage from 1.7GB to 1.1GB and proportionaly reduces
> streaming out time.
>
> Bootstrapped/regtested x86_64-linux.
> OK?

Ok.

Thanks,
Richard.

> Honza
>        * lto-streamer-out.c (lto_output_ts_binfo_tree_pointers): Do not
>        stream BINFO_VIRTUALS to ltrans units.
> Index: lto-streamer-out.c
> ===================================================================
> --- lto-streamer-out.c  (revision 174985)
> +++ lto-streamer-out.c  (working copy)
> @@ -1117,7 +1117,11 @@
>
>   lto_output_tree_or_ref (ob, BINFO_OFFSET (expr), ref_p);
>   lto_output_tree_or_ref (ob, BINFO_VTABLE (expr), ref_p);
> -  lto_output_tree_or_ref (ob, BINFO_VIRTUALS (expr), ref_p);
> +  /* BINFO_VIRTUALS is used to drive type based devirtualizatoin.  It often links
> +     together large portions of programs making it harder to partition.  Becuase
> +     devirtualization is interesting before inlining, only, there is no real
> +     need to ship it into ltrans partition.  */
> +  lto_output_tree_or_ref (ob, flag_wpa ? NULL : BINFO_VIRTUALS (expr), ref_p);
>   lto_output_tree_or_ref (ob, BINFO_VPTR_FIELD (expr), ref_p);
>
>   output_uleb128 (ob, VEC_length (tree, BINFO_BASE_ACCESSES (expr)));
>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-06-14 10:05 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-13 13:11 Do not stream BINFO_VIRTUALs to ltrans unit Jan Hubicka
2011-06-14 10:14 ` Richard Guenther

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