This is the mail archive of the 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: bitmap memory allocation

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.

No kidding.
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 the head
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).

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.
This is correct.

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?


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