SSA annotations memory use.

SSA annotations memory use.

[Jan Hubicka]

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.

Overall the scenario is not _that_ bad as we cleanup code early so
memory peak is actually 20% smaller for Gerald's testcase and 12% bigger
for GCC binarry compared to mainline, but still this looks like quite
bloated stuff.

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?

Honza

Re: SSA annotations memory use.

[Andrew MacLeod]

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?

Andrew

Re: SSA annotations memory use.

[Jan Hubicka]

> 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

Re: SSA annotations memory use.

[Andrew MacLeod]

On Tue, 2004-12-07 at 09:53, Jan Hubicka wrote:
> > On Tue, 2004-12-07 at 09:14, Jan Hubicka wrote:

> > 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...

they wouldn't exist until you go into ssa anyway. They are hung off of
the stmt annotation.

Andrew