On Sun, Nov 25, 2012 at 4:21 PM, Diego Novillo <dnovi...@google.com> wrote: > On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener > <richard.guent...@gmail.com> wrote: > >> I'd say the most pragmatic solution is to stick with gengtype but >> make it more dependent on annotations (thus, explicit). That is, > > Yes. That is the direction in which I've been leaning towards. My > preference is to transitionally move to manual markers > (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives#Do_GC_marking_manually) > and over time transition to memory pool management.
Note that the most GCed thing is a 'tree' and the solution is not to move trees to memory pools but to use less trees in the first place! If trees were not GCed GIMPLE would not be I bet, and thus if GIMPLE would not refer to trees there would be no reason to GC it! Improving things wrt tree usage also means to isolate C/C++ frontend IL from the middle-end. I once proposed to cp tree.[ch] and at gimplification time re-allocate and copy from the frontend tree "kind" to the gimple tree "kind". Of course our FE / middle-end separation enemy (debug info) makes this not so viable at the moment. >> I suppose I agree that garbage collection is not technically >> required for writing a compiler, but getting rid of GC in GCC >> entirely will be a hard and error-prone task (even if you >> factor out PCH which is an entirely different mess). > > Agreed. As far as PCH is concerned, my preferred long term approach > is to move to streamable types. We have an almost working > implementation in the PPH branch and we already have a streaming > framework in LTO. Of course that's not all we preserve in PCH ... (look for "interesting" global data marked as GC root just for the sake of PCH). Richard. > > Diego.
