Re: Phase 1 of gcc-in-cxx now complete

[Ian Lance Taylor <iant at google dot com>]

Matt <matt@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