This is the mail archive of the
mailing list for the GCC project.
Re: bitmap memory allocation
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 12 Nov 2004 09:07:31 -0500 (EST)
- Subject: Re: bitmap memory allocation
- References: <4194BB6C.email@example.com>
On Fri, 12 Nov 2004, Nathan Sidwell wrote:
Bitmaps have four different creation mechanisms,
1) GC allocated head, GC allocated elements
2) malloc'd head, bitmap obstack'd elements
3) stack-frame head, bitmap obstack'd elements
4) obstack'd head, bitmap obstack'd elements
This is confusing and unnecessary.
I actually explained how this all went to someone about a week or two ago,
and as doing it, realized just how messed up it was. :)
Note that #2 and #4 allocate
from a different pool than the elements -- lifetime issues anyone? tree-cse
uses #4 to allocate the heads from one bitmap, but it doesn't do
a bitmap-clear, so the elements are lost on the bitmap obstack itself.
It used to call bitmap_xfree, which did a bitmap_clear for you :)
I think when honza changed it to use the obstack, we both forgot this was
necessary (as you say, it's a mess).
This is correct.
I've added separate bitmap allocators for gc'd, malloc'd and obstack'd
bitmaps. I've added a separate reg_obstack to allocate regsets from.
The bitmap obstacks are initialized and freed within tree-optimize. Both
those obstacks have the same lifetime. I suspect the register obstack need
only exists for the rtl optimizations though.
However, you need a set of obstacks you can use from the cgraph level
(which is before tree-optimize), until the end of compilation.
I had to track down a bug to regset_release on a branch doing IPA
optimizations for this very reason. It just decided it would be a good
idea to blow away all the bitmap obstacks when it was done, which
released memory still in use by IPA analyzers.
booted & tested on i686-pc-linux-gnu, ok?