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

[law at redhat dot com]

In message <200311181801.50659.s.bosscher@student.tudelft.nl>, Steven Bosscher 
writes:
 >On Tuesday 18 November 2003 17:38, law@redhat.com wrote:
 >>  >I've attached a side-by-side comparison of tree allocations for tree-ssa
 >>  > vs. mainline (again without tree PRE).  We allocate 236267452 bytes
 >>  > total for trees with tree-ssa, vs. 102906976 on mainline.  About half of
 >>  > the difference
 >>  >
 >>  >is in the SSA specific nodes, so the rest probably comes from lowering.
 >>  >Considering that we gc_allocate 771097504 bytes total with tree-ssa, vs.
 >>  >441972664 on mainline, this leaves a difference of ~200MB unaccounted
 >>  > for.  I
 >>  >
 >>  >wouldn't expect that to be in extra RTL objects...
 >>
 >> Well, we've clearly got a gazillion more MODIFY_EXPRs.
 >>
 >>  >modify_expr          495487     17837532     1931        46344
 >>  >eq_expr              172928      6225408     1555        37320
 >>  >ne_expr              155772      5607792     2282        54768
 >>
 >> As I pointed out in a previous message, these things stick out like a
 >> sore thumb.
 >
 >Yes, but I had already counted those, so while they stick out, they don't 
 >explain the 200MB.
Presumably you're testing with generate-3.4.ii?  -O2?

Assuming that's the case, roughly 350000 of the 493000 additional MODIFY_EXPR
nodes we create are a direct result of trying to track the result of 
conditionals in the dominator optimizer and the not so pleasant interface
into the main dominator hash table.

Also note that for each of the 350000 MODIFY_EXPRs, we also end up creating
statement annotations which carry no useful information.  While this may
all get garbage collected, that, IMHO is extremely wasteful.




                0.00    0.01    8289/412164      get_eq_expr_value [294]
                0.00    0.02   11682/412164      record_equivalences_from_incom
ing_edge [273]
                0.00    0.06   44057/412164      record_equivalences_from_stmt 
[72]
                0.00    0.24  174068/412164      record_cond_is_true [205]
                0.00    0.24  174068/412164      record_cond_is_false [204]
[114]    1.1    0.01    0.58  412164         blah [114]
                0.27    0.30  412164/6214672     build <cycle 1> [176]



"blah" is a tiny front-end to build which I added to the dominator optimizer
so that I could easily track what routines where creating new MODIFY_EXPR
nodes from within the dominator optimizer.  Of particular interest is the
record_cond_is_{true,false} entries.

In fact, from looking at this, we can see that record_cond_is_{true,false}
account for 5.6% of the calls into build.  Ouch.

I don't expect this will be all that terrible to fix.  Even if it doesn't
help with persistent memory, it should reduce the load on the garbage
collector and help with locality issues.

jeff