This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: Andrew Macleod <amacleod at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 17 Nov 2003 18:55:43 +0100
- Subject: Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
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.
> Yes, we need to look at the entire issue of moving annotations into the
> correct nodes, and what information in the annotations are
> non-overalpping, etc. all that at once. Doesn't that sound like fun?
>
> It seems like it might be best done post-merge with mainline due to the
> conflicts and stuff it would cause when trying to do reverse merges to
> the branch... I suspect thats half the reason it was done this way in
> the first place :-).
(I don't understand this argument. How can a change in a piece of code that is
not in the mainline cause merge trouble? How can removing two fields and
using an existing macro cause merge trouble??? Oh well...)
<SCEPTIC>
A merge with mainline is not going to happen any time soon. In fact I wonder
if there should be a merge _at_all_ unless this memory issue is resolved
_first_. Major changes from branches can only be merged if they cause no
regressions. Right now, tree-ssa basically causes huge regressions in memory
consumption, and these regressions are not easily fixed. Therefore I believe
it should be done pre-merge.
</SCEPTIC>
Gr.
Steven