This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]