[tree-ssa PATCH] Pick memory consumption low hanging fruit

[Steven Bosscher]

On Monday 17 November 2003 20:25, Andrew MacLeod wrote:
> Lets not throw too much of the blame in one place. I looked at 12524 a
> while ago. First, there are known memory problems with PRE. Turn off pre
> when you have serious memory problems. Second, try turning off SSA.

<grin> That's going to help if you want to use tree SSA :-)

> Gimplification is a part of the problem too. We've made numerous changes
> to the amount of memory other optimizations consume in tree SSA. The
> last time I looked at it, without PRE, tree SSA didnt end up changing
> the memory footprint in a really significant way over what it did with
> just gimplification.

True.

> What does the memory footprint look like know when you compile with
> -fdisable-ssa...  If that doesnt make much difference, you can hack at
> the SSA data structures all you want and it isnt going to affect memory
> consumption in any measurable way. If there is a 40% increase then we
> have something that needs to be fixed. I dont klnow if we've crept back
> up or not since Ive been more focused on runtime for the last few weeks
> since then.

I don't think the SSA data structs are the real problem, though they could use 
a diet, too.

> We have to measure exactly where all the memory is going before we can
> fix it.

I was trying to figure that out this weekend, but it's tough.

One thing that could be causing some of this trouble is that we lose big time 
when lowering, because we don't garbage collect after lowering in t_r_o_c, 
which we can't do effectively anyway if nested_p is set.  And it probably 
_is_ set most of the time with code with lots of templates.
If this observation is true, then we end up with lots of garbage in a 
different GC context and we may not be able to collect it for a long time to 
come (not until finishing the template instantiation???). 

We also cannot collect between optimizations because basic blocks are not 
GC'ed so we sometimes collect PHI nodes (had fun with that this weekend, with 
tree check failures and al.  Fun!), but that is probably not such a big 
problem.

Anyway, I suppose you already knew all this of course.  So not much help here, 
like I said it's tough...  :-(

> SSA only keeps its information around a function a time. The memory
> charactaristics I saw with the PR were a reasonably monmotonically
> increasing usage of memory, with or without SSA. It seems to me there
> are a lot of trees being kept around, and it would appear to me that
> there are places other than the SSA data structures that need to be
> examined first.

OK.

> Its high on our todo list, but we're just not quite there yet as we deal
> with all these lowering issues. I also dont know much about the trees
> and the organization of the earlier passes like gimplification, so that
> area is a lot harder and less inviting for me to look at :-).

A good start would be figuring out how much memory lowering actually costs, 
and how much of the garbage it produces we can actually reclaim.  I can 
probably find some time to investigate this a bit if y'all don't know much 
about this already.

Gr.
Steven