Matt <m...@use.net> writes: >> * Develop some trial patches which require C++, e.g., convert VEC to >> std::vector. > > Do you have any ideas for the easiest starting points? Is there > anywhere that is decently self-contained, or will if have to be a big > bang?
Thanks for your interest. I think the one I mentioned--converting VEC to std::vector--is a good starting point. This is the interface in vec.h. Another easy starting point would be converting uses of htab_t to type safe C++ hash tables, e.g., std::tr1:;unordered_map. Here portability suggests the ability to switch to different hash table implementations; see gold/gold.h in the GNU binutils for one way to approach that. Another easy starting point is finding calls to qsort and converting them to std::sort, which typically leads to code which is larger but runs faster. Longer term, we know that memory usage is an issue in gcc. In the old obstack days, we had a range of obstacks with different lifespans, so we could create RTL with a temporary lifetime which was given a longer lifetime when needed. We got away from that because we spent far too much time chasing bugs in which RTL should have been saved to a longer lifetime but wasn't. However, that model should permit us to run with significantly less memory, which would translate to less compile time. I think we might be able to do it by implementing a custom allocator, such as a pool allocator which permits allocating different sizes of memory, and never frees memory. Then the tree class could take an allocator as a template parameter. Then we would provide convertors which copied the tree class to a different allocation style. Then, for example, fold-const.c could use a temporary pool which lived only for the length of the call to fold. If it returned a new value, the convertor would force a copy out of the temporary pool. If this works out, we can use type safety to enforce memory discipline, use significantly less memory during compilation, and take a big step toward getting rid of the garbage collector. Ian
