Re: RFC - Alternatives to gengtype

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Mon, 19 Nov 2012, Lawrence Crowl wrote:
> On 11/17/12, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> > On Thu, 15 Nov 2012, Diego Novillo wrote:
> > > === Approach: Move GTY to cc1plus.
> > >
> > > Instead of a separate weak parser, we would make cc1plus
> > > understand GTY attributes.  The compiler would emit IL in the
> > > object files instead of generating source.
> > >
> > > This solution would require a first boot stage that did not
> > > support PCH, because we cannot rely on the seed compiler
> > > supporting GTY.  We would probably need to use the Boehm
> > > collector during the first stage as well.
> > >
> > > Because the first stage would be fundamentally different from the
> > > second stage, we may need to add an additional pass for correct
> > > object file comparisons.
> >
> > It sounds like this would, for cross-compilers, require a native
> > GTY-savvy g++?  Please no.
>
> We cannot require a GTY savy seed compiler.  In part, at least,
> because we do not have one now.  :-)
>
> So, the GTY annotations would need to be invisible to the seed
> compiler.  The implication is that the first built compiler does
> not have GGC and PCH.  The first built compiler would, however,
> recognize GTY, and the second (and subsequent) built compiler would
> have these features.

JFTR: above, I'm very explicitly referring to cross-compilers.
For your comments above to be relevant to them, you seem to
imply a different workflow for building cross-compilers than the
current, in which one and the same host compiler builds a
cross-compiler in a single stage.  Currently there's no "second
(and subsequent) built compiler" for the cross-compiler-build
scenario; if you're referring to the just-built cross-compiler
it doesn't matter whether it's GTY-savvy.  Just mentioned in
case this becomes relevant again; with Boehm GC or
reference-counting pointers (I hope) it doesn't matter.

It's similar to the native-compiler scenario only as far as
requirements for the host compiler (compiling the first stage);
you can "fix" both scenarios by requiring the host-compiler to
be GTY-savvy.  But for that to IMHO be tolerable, a few versions
of GTY-savvy GCC have to be released before making any such a
requirement.  Not to mention that the first such release would
likely contain bugs serious enough to be unusable for later
versions.  But you already agree that's not what should happen,
so mentioned JFTR.

> Because the first built compiler would not have GGC, we need some
> other memory management, and the Boehm collector is the nearest
> handy tool.

I'd think the reference-counting-pointer scheme mentioned by
others would be preferable as requiring less memory overhead but
there you go.  Trading one GC for another is simpler and better
I guess, at least as a functional intermediate step.  Maybe
refcounting pointers can be better introduced later, if ever and
measurably better.

brgds, H-P