[PATCH] Canonical types (1/3)

Jan Hubicka hubicka@ucw.cz
Wed Jan 3 21:09:00 GMT 2007


> On 1/3/07, Doug Gregor <doug.gregor@gmail.com> wrote:
> >On 1/2/07, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> just for a record, this is memory tester report about this patch.  I
> >> think all the increases (generally in between 1-2% except for extreme
> >> case of empty function) comes from extra field in the type tree node.
> >> I would be bit curious why we produce so many types for empty function
> >> we manage to gabrage collect somehow ;)
> >
> >Thanks for the report. We knew that the patch improved compile-time
> >performance at the cost of higher memory utilization, but I hadn't
> >quanitified it.
> 
> Uh, if you look at the numbers for the tramp3d tester
> (http://www.suse.de/~rguenther/c++bench/tramp3d/) memory usage
> increased
> by 30% (!), compile time increased as well.  [I don't have access to the 
> machine
> hosting the tester at the moment, so I cannot see if IPA SSA enabling is in 
> the
> set of changes]
> 
> So definitely something you or honza can look at?

I am looking into it.  I think it is more likely IPA SSA from major
part.  Something weird is however going on when compiling Gerald's
tramp3d:
 tramp3d-v4.cpp:55266: warning: canonical types differ for identical  types Mesh<MeshTraits<3, T, MeshTag, SphericalTag, 3> > and > Mesh<MeshTraits<3, T,
+MeshTag, SphericalTag, 3> >
  <bound_template_template_parm 0x2ba077eb06c0 Mesh type_0 type_6 VOID
     align 8 symtab 0 alias set -1 canonical type 0x2ba077eb06c0
    index 0 level 1 orig_level 2
     chain <type_decl 0x2ba078e8fb60 Mesh>>
  <bound_template_template_parm 0x2ba07810b3c0 Mesh type_0 type_6 VOID
     align 8 symtab 0 alias set -1 canonical type 0x2ba07810b3c0
    index 0 level 1 orig_level 2
     chain <type_decl 0x2ba078e8fb60 Mesh>>

I would expect those to be ICE and not happening at all.

>From quick check, the IPA passes together on mainline now makes GGC
memory to go up from 276MB to 454MB.  Not all of this is SSA, but
overall peak memory increase caused by IPA-SSA merge should not exceed
that 200MB, while we see a lot more, so something fishy is going on.

Richard, do you happen to have at least -Q reports before and after?
Scores don't seem at all that bad in my testing.
One problem is that we now seem to continue sink in memory usage after
doing all IPA passes that is wrong and indicate that we are leaking some
pointers to function bodies somewhere.  I am looking after that.

Honza
> 
> Thanks,
> Richard.



More information about the Gcc-patches mailing list