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

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2003-11-17 at 12:55, Steven Bosscher wrote:
> On Mon, 2003-11-17 at 11:59, Andrew MacLeod wrote:
> > On Mon, 2003-11-17 at 11:25, law@redhat.com wrote:
> > > I would *much* prefer we take a systematic approach to this problem --
> > > ie,  rather than moving one bit around at a time, let's think a little
> > > longer term about the entire scheme for annotations, pass-local flags
> > > and the like.    Moving bits into the tree common flags right now is
> > > IMHO premature.
> 
> Perhaps it's premature to you, IMHO it is _way_ overdue.  To me it is a 
> serious problem that tree ssa sucks up more memory than my machine has.
> 
> I cannot even compile a decent C++ code because my machine goes out of memory 
> and kills the compiler.  And I bet I am not the only one with this problem.  
> Now my machine has "only" 768MB of virtual memory, but no compiler should 
> require that much to be able to compile a reasonable application.  There are 
> applications where tree-ssa eats up 5-10 times as much memory as, say, 
> 2.95.3.  To some people, it is completely unusable.
> 
> Don't get me wrong, I don't care much that no-one likes the patch.  But can 
> you then please move this memory consumption issue somewhat closer to the top 
> of the TODO list? PR 12524 has been around for a month and a half now, things 
> only have gotten worse since then, and no-one has taken a serious look at it.
>  

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.
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. I think it was about 60MB out of the whole thing at
the highwater mark vs. NON-ssa, and we do need to temporararily consume
some.

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.

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

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.

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



Andrew