This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, Andrew Macleod <amacleod at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 17 Nov 2003 15:22:56 -0700
- Subject: Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- Reply-to: law at redhat dot com
In message <email@example.com>, Diego Novillo
>On Mon, 2003-11-17 at 12:55, Steven Bosscher wrote:
>> 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.
>We're not feature-complete yet. We have been adding/removing fields
>from the annotations all along. It's not even clear whether we want to
>keep them long term. Some of them may become on-the-side hash-tables or
>be moved into tree structures.
Yup. Let's take the OCCURS_IN_ABNORMAL_PHI as an example. It's something
we need through the SSA passes, but it doesn't necessarily have to be in
the annotation. We could (for example) make it a bitmap indexed by the
variable's uid. Even for C++ and Java code I would expect that to be a very
This would have the advantage that you release the memory for this data
is allocated, then tossed away when we're done optimizing the function.
Contrast that to shoving it in the tree flags -- at which point you have
spend a nontrivial amount of brainpower determining what bit is actually
safe to use. And every time we use one of the bits for this purpose we
the task of finding a free bit for truly long-lived data that much harder.
>Having said that, feel free to attack the problem. I don't think we
>even know where our big memory problems are. We have some idea, but I
>don't remember seeing a thorough analysis. To begin with, does PR 12524
>represent all the memory problems we have? Are there other test cases
>that show different problems? I know, for instance, that Gerald's
>application kills my 256Mb box. I can't file a PR for it, but I'll get
>to it eventually.
And as I've said before, I would be most grateful if someone could start
getting some data on where the memory's going. Until we know that, trying
to optimize memory consumption is very much a hit or miss proposition.
Steven, if you want to help, get some data on how the memory allocation
characteristics of the tree-ssa code differs from the mainline. Hell,
even knowing how it behaves with/without the optimizers would be awful