Fix memory corruption in operands

Jan Hubicka jh@suse.cz
Mon Jan 22 18:21:00 GMT 2007


> On Mon, 2007-01-22 at 17:36 +0100, Jan Hubicka wrote:
> > > On Sun, 2007-01-21 at 04:08 +0100, Jan Hubicka wrote:
> > > > Hi,
> 
> > > I think we discussed being able to use the free-list in a global way
> > > back when you were doing the initial file conversions. There is no
> > > reason that can't be done.   
> > > 
> > > we shouldn't be leaking any operands, it should be an enclosed system.
> > 
> > Good, so we take care to remove operands of all dead statements and put
> > them back to freelist, right?
> 
> as long as the annotation is freed, they end up in the free list. Right
> now, we never lose anything in a function because when we free SSA,
> *all* the pointers to operands are allocated from the memory chunks
> which are managed by the operand cache. At the point, even if we had
> lost the handle to some of the memory via stray annotations that got
> lost, freeing the cache up still makes the memory go away for the
> operand cache.  
> 
> you will of course lose that if you go to a global list because the
> cache will never be freed up until the last function is processed.  It
> boils down to how well we manage the annotations. As far as I know, they
> should be handled reasonably well.  If we don't, They certainly should
> be anyway :-)

Well, the only place we call free_ssa_operands is from delete_ssa, so
all stmt annotations for statments elliminated by DCE and others are
left dead for a moment I blieve.
Just to get some hard data, at the end of compilation we have for
combine.c:

tree-ssanames.c:143 (make_ssa_name)                 1367136: 4.1%          0: 0.0%          0: 0.0%          0: 0.0%      28482
tree-inline.c:2754 (copy_tree_r)                    1372400: 4.2%          0: 0.0%          0: 0.0%      17356: 0.5%      37765
tree-dfa.c:189 (create_stmt_ann)                    1433432: 4.3%     866376: 6.3%          0: 0.0%          0: 0.0%      41068
genrtl.c:17 (gen_rtx_fmt_ee)                        1885404: 5.7%          0: 0.0%       1956: 0.1%          0: 0.0%     157280
Total                                              32996633         13710922          3145510          3307173          1365803
source location                                     Garbage            Freed             Leak         Overhead            Times

(this show that stmt annotations are one of major memory consumers, but
also that amount of them allocated by left unfreeded to them freeded is
something like 4:6.  This seems like pretty big leak for freelists.  It
is of course bigger when amount of dead code increase, ie for example in
tramp3d).

Just for the promised data, after IPA (ie when all functions reside in
memory in SSA form) the footprint is:

gimplify.c:455 (create_tmp_var_raw)                    9504: 0.2%          0: 0.0%     508376: 4.7%          0: 0.0%       5885
optabs.c:4986 (new_convert_optab)                         0: 0.0%          0: 0.0%     602212: 5.6%     176228:27.0%         13
tree-ssanames.c:143 (make_ssa_name)                   99840: 1.7%          0: 0.0%     612864: 5.7%          0: 0.0%      14848
tree-ssa-operands.c:490 (ssa_operand_alloc)               0: 0.0%          0: 0.0%     867167: 8.1%      33631: 5.2%        151
tree-inline.c:2754 (copy_tree_r)                      41148: 0.7%          0: 0.0%    1009396: 9.4%      14484: 2.2%      28558
tree-dfa.c:189 (create_stmt_ann)                     289184: 4.8%          0: 0.0%    1111768:10.3%          0: 0.0%      25017
Total                                               6014810           340680         10769570           652312           375815

So 10% are the live statement annotations (20% of statement annotations
are already gabrage collected), 8% operand caches.  Again it is more
steep for tramp3d even tough there it is partly covered by dead C++
frontend datastructures still being resident.
>  
> At least I believe that to be true. Hmm.  Perhaps we better verify
> it :-)  We definitely manage it properly when operands are updated  by
> the cache routines.

Which is one of few places where we get the freelists right, sadly.
> > I am evaulating posibility to build aliasing.  Early results show about
> > 100MB memory increase on tramp3d that is not _that_ bad.  But I still
> > can't compile non-trivial testcases so I don't know what the final
> > outcome might be.
> 
> I would actually have expected the virtual operands to chew up more
> memory than the real operands.  How much memory do the operands consume
> on tramp3d? perhaps we aren't freeing enough stuff from the
> annotations...

I still have just a rough numbers on tramp3d, but I will try to produce
something more precise and tell you.
But the 100MB was naturaly combination of virtual operands, aliasing
tables and such.  Everything is pretty big and has tendency to explode
in side cases that is what makes me bit cureful about pushing it to IPA
level.  I would be sad if 4.3 consumed a lot more memory than previous
releases just because of the IPA-SSA projects (and I am happy the
numbers so far seems to be showing the contrary).

Honza
> 
> Andrew



More information about the Gcc-patches mailing list