This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC - Alternatives to gengtype


On Sun, Nov 25, 2012 at 10:45 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Sun, Nov 25, 2012 at 4:21 PM, Diego Novillo <dnovillo@google.com> wrote:
>> On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener
>> <richard.guenther@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!

True, but you are describing an orthogonal problem.  There are other
data structures in GC.  Long term, I would like to move all of them
out of GC.

> 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.

Right.

>
>>> 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).

That's fine.  We can stream that data as well.  Identifying all that
is also helpful to realize just how much loose global state we have.
Coalescing that global state would be a good cleanup too.


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]