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

[<judd dot jenne at charter dot net>]

This thought came to mind (so I decided to delurk and 
ask)...

Does cgraph queue functions at the earliest low water mark 
(post parsing perhaps)? [perhaps improve footprint and 
locality?]

Is cgraph able to spot obvious inlining decisions so as to 
finalize and emit obvious portions of the call graph early 
on and work towards a reduced footprint? [Iterative 
analysis trading off between per function footprint and 
potential for completing/finalizing subgraphs (better 
information, more opportunities to finalize??) (global 
footprint).]

I haven't looked at the code for cgraph on tree-ssa in a 
few months, but at the time, (I could be mistaken) that 
functions were gimplified then queued.  Is gimple more 
compact than the format produced by the various FEs?

Judd

p.s. If nothing else, these forums make for both 
entertaining and educational reading <grin>.

<quote Andrew MacLeod>
A lot fo the memory swapping appears to be locality. When 
I stopped
looking at it, I has the user time virtually the same for 
tree-ssa and
mainline. (within a few of percentage points). Overall 
compile time was
50% higher purely due to the additional swapping we were 
doing, so
overall time was a lot slower. SO the locality of the 
things we are
keeping and accessing appear to be quite horrible.  Again, 
I would
predict this is going to be cross functional information. 
SSA itself
tends to iterate over the same things and create a few 
nerw things. I
recall a lot of the lost swap time was in the parser 
pahse, so it would
seem that everything the parser was using was getting 
swapped out in
SSA, and then swapped back in again when we move on to the 
next
function.
</quote>