> 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 ...
Hmm, so i guess I should walk into ORIGINAL_TYPE when seeing TYPE_DECL? Honza
