This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SSA annotations memory use.
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, Diego Novillo <dnovillo at redhat dot com>,stevenb at redhat dot com, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Tue, 7 Dec 2004 15:53:47 +0100
- Subject: Re: SSA annotations memory use.
- References: <20041207141417.GN8515@kam.mff.cuni.cz> <1102430351.31213.10.camel@pain>
> On Tue, 2004-12-07 at 09:14, Jan Hubicka wrote:
> > Hi,
> > I've been looking into memory usage of tree-profiling branch and after
> > parsing combine.c roughly 25% is consumed by CFG related datastructurs.
> > 3% are adges, 2.7% tsi linked lists, 6.6% blocks, 7% labels, 13%
> > statement annotations.
>
> >
> > I think I can get the CFG usage down by splitting up the info used by
> > RTL only to be allocated on local basis and prune out some unneded stuff
> > from edges and blocks, but the major part are the labels and
> > annotations. Are there any current plans on getting these smaller?
> > (one obvious idea is to kill the annotations once function is analyzed
> > and recompute them when it is being compiled, but this is side step from
> > plan to build and preserve SSA), but perhaps we can think of breaking it
> > up to part that survive from analysis to compilatio and part that will
> > get recomputed cheaply?
>
> you could try getting rid of all the stmt operand caches until you need
> them again. They could be a good percentage chunk of the annotation, and
> they are just going to get larger in 4.1 when the immediate use info is
> integrated.
>
> when you analyze the function, how far into the compilation process do
> you go?
Not far at the moment - only cleanup the cfg and instrument for
profilng. Of course the plan is to optimize harder at this stage.
Also I would expect that the caches would show up as different field in
-fmem-report dump...
Honza
>
> Andrew