This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Re-write LTO type merging again, do tree merging
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, Jan Hubicka <jh at suse dot de>, Diego Novillo <dnovillo at google dot com>, andi at firstfloor dot org, Michael Matz <matz at suse dot de>
- Date: Fri, 14 Jun 2013 00:16:35 +0200
- Subject: Re: [PATCH][RFC] Re-write LTO type merging again, do tree merging
- References: <alpine dot LNX dot 2 dot 00 dot 1306121447210 dot 26078 at zhemvz dot fhfr dot qr> <alpine dot LNX dot 2 dot 00 dot 1306131022370 dot 26078 at zhemvz dot fhfr dot qr> <alpine dot LNX dot 2 dot 00 dot 1306131614000 dot 26078 at zhemvz dot fhfr dot qr> <20130613213705 dot GA1358 at atrey dot karlin dot mff dot cuni dot cz>
> >
> > Ok, not streaming and comparing TREE_USED gets it improved to
>
> I will try to gather better data tomorrow. My mozilla build died on disk space,
> but according to stats we are now at about 7GB of GGC memory after merging.
> I was playing with the following patch that implements testing whether types
> are same in my (probably naive and wrong) understanding of ODR rule in C++
So i can confirm that we now need 3GB of TMP space instead of 8GB with earlier
version of patch. I will compare to mainline tomorrow, but I think it is
about the same.
phase opt and generate : 96.39 ( 9%) usr 40.45 (45%) sys 136.91 (12%) wall 271042 kB ( 7%) ggc
phase stream in : 457.87 (43%) usr 8.38 ( 9%) sys 466.44 (40%) wall 3798844 kB (93%) ggc
phase stream out : 509.39 (48%) usr 40.82 (46%) sys 550.88 (48%) wall 7149 kB ( 0%) ggc
ipa cp : 13.62 ( 1%) usr 5.00 ( 6%) sys 18.61 ( 2%) wall 425204 kB (10%) ggc
ipa inlining heuristics : 60.52 ( 6%) usr 36.15 (40%) sys 96.71 ( 8%) wall 1353370 kB (33%) ggc
ipa lto decl in : 346.94 (33%) usr 5.49 ( 6%) sys 352.60 (31%) wall 7042 kB ( 0%) ggc
ipa lto decl out : 481.19 (45%) usr 23.28 (26%) sys 504.68 (44%) wall 0 kB ( 0%) ggc
TOTAL :1063.67 89.65 1154.26 4078436 kB
So we are still bound by streaming. I am running -flto-report overnight.
My ODR patch finds 36377 matches and also weird looking mismatches of type:
<record_type 0x7fbd30d46dc8 sockaddr_storage BLK
size <integer_cst 0x7fbd416bc1e0 type <integer_type 0x7fbd415660a8 bitsizetype> constant 1024>
unit size <integer_cst 0x7fbd416bc700 type <integer_type 0x7fbd41566000 sizetype> constant 128>
align 64 symtab 0 alias set -1 canonical type 0x7fbd30f0bc78
fields <field_decl 0x7fbd30e99ed8 ss_family
type <integer_type 0x7fbd3b98c000 sa_family_t public unsigned HI
size <integer_cst 0x7fbd41555fe0 constant 16>
unit size <integer_cst 0x7fbd4156a000 constant 2>
align 16 symtab 0 alias set -1 canonical type 0x7fbd41566540 precision 16 min <integer_cst 0x7fbd4156a020 0> max <integer_cst 0x7fbd41555fc0 65535>>
unsigned nonlocal HI file /usr/include/bits/socket.h line 189 col 0 size <integer_cst 0x7fbd41555fe0 16> unit size <integer_cst 0x7fbd4156a000 2>
align 16 offset_align 128
offset <integer_cst 0x7fbd41555d60 constant 0>
bit offset <integer_cst 0x7fbd41555de0 constant 0> context <record_type 0x7fbd30d46dc8 sockaddr_storage>
chain <field_decl 0x7fbd30e99000 __ss_align type <integer_type 0x7fbd415667e0 long unsigned int>
unsigned nonlocal DI file /usr/include/bits/socket.h line 190 col 0
size <integer_cst 0x7fbd41555d20 constant 64>
unit size <integer_cst 0x7fbd41555d40 constant 8>
align 64 offset_align 128 offset <integer_cst 0x7fbd41555d60 0> bit offset <integer_cst 0x7fbd41555d20 64> context <record_type 0x7fbd30d46dc8 sockaddr_storage> chain <field_decl 0x7fbd30e99e40 __ss_padding>>> context <translation_unit_decl 0x7fbd30cbc2e0 D.967968>
chain <type_decl 0x7fbd30d47da8 sockaddr_storage>>
<record_type 0x7fbd30f0bc78 sockaddr_storage BLK
size <integer_cst 0x7fbd416bc1e0 type <integer_type 0x7fbd415660a8 bitsizetype> constant 1024>
unit size <integer_cst 0x7fbd416bc700 type <integer_type 0x7fbd41566000 sizetype> constant 128>
align 64 symtab 0 alias set -1 canonical type 0x7fbd30f0bc78
fields <field_decl 0x7fbd30ef9558 ss_family
type <integer_type 0x7fbd3b98c000 sa_family_t public unsigned HI
size <integer_cst 0x7fbd41555fe0 constant 16>
unit size <integer_cst 0x7fbd4156a000 constant 2>
align 16 symtab 0 alias set -1 canonical type 0x7fbd41566540 precision 16 min <integer_cst 0x7fbd4156a020 0> max <integer_cst 0x7fbd41555fc0 65535>>
unsigned HI file /usr/include/bits/socket.h line 189 col 0 size <integer_cst 0x7fbd41555fe0 16> unit size <integer_cst 0x7fbd4156a000 2>
align 16 offset_align 128
offset <integer_cst 0x7fbd41555d60 constant 0>
bit offset <integer_cst 0x7fbd41555de0 constant 0> context <record_type 0x7fbd30f0bc78 sockaddr_storage>
chain <field_decl 0x7fbd30ef94c0 __ss_align type <integer_type 0x7fbd415667e0 long unsigned int>
unsigned DI file /usr/include/bits/socket.h line 190 col 0
size <integer_cst 0x7fbd41555d20 constant 64>
unit size <integer_cst 0x7fbd41555d40 constant 8>
align 64 offset_align 128 offset <integer_cst 0x7fbd41555d60 0> bit offset <integer_cst 0x7fbd41555d20 64> context <record_type 0x7fbd30f0bc78 sockaddr_storage> chain <field_decl 0x7fbd30ef9428 __ss_padding>>> context <translation_unit_decl 0x7fbd30ea9f18 D.936417>
pointer_to_this <pointer_type 0x7fbd30f0bd20> chain <type_decl 0x7fbd30ea9398 D.938243>>
that mismatch because we run into following difference:
<type_decl 0x7fbd30d47da8 sockaddr_storage
type <record_type 0x7fbd30d46dc8 sockaddr_storage BLK
size <integer_cst 0x7fbd416bc1e0 constant 1024>
unit size <integer_cst 0x7fbd416bc700 constant 128>
align 64 symtab 0 alias set -1 canonical type 0x7fbd30f0bc78
fields <field_decl 0x7fbd30e99ed8 ss_family type <integer_type 0x7fbd3b98c000 sa_family_t>
unsigned nonlocal HI file /usr/include/bits/socket.h line 189 col 0
size <integer_cst 0x7fbd41555fe0 constant 16>
unit size <integer_cst 0x7fbd4156a000 constant 2>
align 16 offset_align 128
offset <integer_cst 0x7fbd41555d60 constant 0>
bit offset <integer_cst 0x7fbd41555de0 constant 0> context <record_type 0x7fbd30d46dc8 sockaddr_storage> chain <field_decl 0x7fbd30e99000 __ss_align>> context <translation_unit_decl 0x7fbd30cbc2e0 D.967968>
chain <type_decl 0x7fbd30d47da8 sockaddr_storage>>
public VOID file /usr/include/bits/socket.h line 187 col 0
align 8 context <translation_unit_decl 0x7fbd30cbc2e0 D.967968>>
<identifier_node 0x7fbd30f06d70 sockaddr_storage>
I am not sure what means that one type has more TYPE_DECLs stacked than the other.
Honza