On Fri, 14 Jun 2013, Jan Hubicka wrote: > > > > > > 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.
I think that's the usual case of two nearly identical types in the _same_ SCC, linked through one of the types TYPE_DECL DECL_ORIGINAL_TYPE. The C++ frontend likes to produce those ... They are accounted as the "are in the same SCC" in the stats (for the latest updated patch): [WPA] Old merging code merges an additional 41493 types of which 21633 are in the same SCC with their prevailing variant (415188 and 324371 associated trees) I'm looking into other things now and for example see TYPE_ALIAS_SET issues (we do stream only alias sets -1 and 0, but whether -1 got transformed to 0 at compile-time depends on whether get_alias_set was called on it). That's one case where we can either forcefully call get_alias_set at streaming time, introduce a predicate type_would_have_alias_set_zero that doesn't run the whole get_alias_set machinery, or ignore this for merging and make sure to merge -1 and 0 as 0 (the whole 0 vs. -1 special-case is to support TUs compiled with -fno-strict-aliasing linked together with -fstrict-aliasing TUs). Richard.
