On Sun, Nov 25, 2012 at 7:45 AM, Richard Biener <richard.guent...@gmail.com> wrote: > 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".
Isolation can help but if FE creates too many unused trees and leave them for ME to clean up, I wonder how effective it wil be -- It is not uncommon to see C++ FE generate > 200k functions (by looking at funcdef_no value) from a moderately sized source. David > 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.
