This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ping patch] enhancing gengtype for plugins?
Rafael Espindola wrote:
Bootstrapped on x86_64-linux-gnu (Debian/Sid/AMD64). The extra functionality
has been tested - see
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00255.html.
The usual functionality (the GTY handling inside GCC) did not change.
A very big thanks for reading my patch
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01005.html . I was almost
depressed nobody took his time to read it.
Ok for trunk?
I like the idea, but I am not familiar with the gc or gentype.
I am beginning to believe that I am more familiar with GGC than a lot of
other people.
Do you have a small plugin that uses this? Would you mind adding it to
the testsuite? You might have to edit the .exp to tell it how to run
gentype...
I don't have any *small* plugin that uses that. I have MELT that uses
it, but MELT is definitely not a *small* plugin (and I am not able to
make it much smaller).
(To be exact, I need this gengtype patch
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01005.html to be accepted
to make MELT a plugin itself).
Besides, having my gengtype patch accepted in the trunk is, in my
current perception, the last feature I need in trunk to be able to
pluginify MELT (and this matters a lot to me; I understood that MELT
would never be used unless it is a plugin, because compiling an entire
GCC branch is too big an effort for most people [outside of the GCC
community]).
On a more philosophical view:
* the ability to generate extra GGC roots is essential for the use of
PLUGIN_REGISTER_GGC_ROOTS (which has already been accepted inside the
trunk). To use this PLUGIN_REGISTER_GGC_ROOTS feature, you really need
to generate extra GGC roots, and to do that, you need the functionality
my gengtype patch provides. The only other (ugly & dirty & shameful) way
would be to hack on one's private branch gengtype to generate the
gt-plugin.h file, which means hacking gengtype to do what my small patch
provides.
* I would suppose that in practice, only significant plugins (this in
practice means "big" plugins, requiring more than a person-year to
develop them) would want to register extra roots using
PLUGIN_REGISTER_GGC_ROOTS.
* I cannot imagine any small plugin, suitable for testsuite integration,
which really would require a non-empty table to be registered with
PLUGIN_REGISTER_GGC_ROOTS. And most importantly, to really exercise this
feature (which is a trivial feature for any one understanding how
garbage collectors work!) you'll need to have cc1 do complex enough
things so that the GGC is really called inside the plugin.
* Hence, in pratice, I believe that most robust testcases for these
features would be much much larger that the small gengtype patch I am
proposing. I could try to develop such a testcase if people care about
it. I definitely would prefer it to be a pluginified MELT, but by no
means I am daring suggest that MELT would go into the testsuite (since
MELT is really a big lot of code). But assuming I take a lot of time to
make a real testcase for these features, who would review a much bigger
patch than the one (on gengtype) we are talking about?
(FWIW, I am very scared each time I am submitting a patch to the trunk;
my major concern is that nobody cares).
Please help me by explaining me what should I do to get this small
gengtype functionality accepted inside the trunk. I am lost! Should I
take a lot of time to develop an ad-hoc plugin which exercise this
feature as a test case (but then, the testcase would be much bigger than
the gengtype patch I am trying to push, and I believe a big patch has
much less chances to be accepted than a small one)?
Having this gengtype patch
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01005.html be accepted in
the trunk is very important to me (because it would enable me to
pluginify MELT, which is important to me), but I don't know what to do
(and I am scared to annoy the few people willing to review it)!! Please
tell me what do!! I'll do almost anything honest to have it accepted in
the trunk!
And please be kind with me: there are a big lot of cultural & linguistic
differences between you and me (in particular, I am not a native English
speaker, & I don't live in a north American corporate culture).
The major point of my
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01005.html gengtype patch
is that it should be easy to review, since it is simple & short. I do
admit it is not very elegant, since it just avoid printing (the
non-plugin generated part) in gengtype. But gengtype is running fast
enough, and most importantly, is only useful at plugin or trunk build
time (the gengtype code is never used in an actual cc1 invocation; what
is used is code generated by gengtype!)
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***