On Sat, Jun 27, 2009 at 2:55 AM, Ian Lance Taylor<i...@google.com> wrote: > 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.
All that above said - do you expect us to carry both vec.h (for VEC in GC memory) and std::vector (for VECs in heap memory) (and vec.h for the alloca trick ...)? Or do you think we should try to make the GTY machinery C++ aware and annotate the standard library (ick...)? That said - I was more expecting to re-write the existing vec.h to C++ to avoid this GC vs. non-GC use differences. Also as the standard library uses a very inefficient allocator by default, should we for example switch from bitmap to an equivalend standard library container. IMHO we should at least try without the standard library for a start, fixing the GTY machinery. Richard.
