Re: [PATCH, MELT] add dominance functions

[Basile Starynkevitch <basile at starynkevitch dot net>]

On Sun, 22 May 2011 15:24:30 +0200 (CEST)
Gerald Pfeifer <gerald@pfeifer.com> wrote:

> On Fri, 20 May 2011, Basile Starynkevitch wrote:
> > By the way, I am quite happy of Pierre patches to the MELT branch. Is 
> > this enough to get him a write access to GCC SVN (all legalese is done)? 
> > I fear that to really get that write access, Pierre would also need to 
> > have accepted patches to the trunk (i.e. that writing good patches to a 
> > branch is not enough)... I still don't understand the criteria to admit 
> > Pierre to the Write After Approval list of maintainers with a write 
> > access to GCC SVN...
> 
> This indeed is a bit of an unusual situation.  Are you planning to,
> realistically, merge the MELT branch into mainline at one point?

I am dreaming of either merging MELT into mainline, or at least having
it be an essential GCC plugin distributed with GCC.... (ideally, I
would prefer MELT to be merged, because that would give it more
visibility). 

But I don't know how realistic is that dream. And I even don't know how
to make it happen. (The main issue being: who will review a 60KLOC
patch, most of it being in a "bizarre" language, MELT itself??)

As I told in informal discussions at some GCC Summits, I feel that MELT
is or may become a bit like the tree-browser.c : something useful
enough to some people to be integrated into mainline, even if most GCC
users don't even know about that functionality, and don't care or use
it when compiling their software. I am quite sure that 99% of GCC users
don't need or know about tree-browser.c and could use GCC with the
tree-browser disabled! I believe it could be the same for MELT: it
would be useful to a small fraction of users, but to them it would
bring enough value.

I am believing that Pierre's work can indeed attract much more attention
to MELT, because it shows very well MELT's interest: providing a
higher-level formalism which makes possible extra features (e.g.
specific warnings, in Pierre's GSOC work case) which would not be
realistically or economically possible without MELT.


The point is that MELT is usually quite near to the mainline: we
carefully avoid adding things into MELT which make MELT incompatible
with the mainline (unless we believe it shows a feature which should be
accepted), because we strongly want MELT to be either compilable as a
branch or as a plugin (to the next GCC release).

To be more specific, the difference between MELT (as a branch) and the
trunk are two lines in gengtype.c, a few lines in toplevel.c, some
additional options & parameters (common.opt, params.def), and the whole
MELT infrastructure (melt-runtime.[ch], melt/generated/*, melt/*) which
is by default disabled. So the behavior of the MELT branch when no MELT
specific program options are given is exactly the behavior of the trunk
(which was last merged into MELT). This is done on purpose, because
MELT can also be built and used as a GCC plugin, so its behavior is
"plugin-like": unless enabled (by options -fmelt*), MELT branch does
exactly what the trunk do. And even when required by -fmelt* arguments
to cc1, MELT branch behavior is exactly that of the melt.so plugin
(except that arguments which are -fmelt* to the MELT branch becomes
-fplugin-arg-melt-* arguments for -fplugin=melt). Internally, the MELT
branch registers a pseudo builtin/MELT plugin and uses the plugin hooks
(only when enabled).

The distributed MELT plugin is made of files extracted from the MELT
branch: the melt.so plugin is obtained by compiling melt-runtime.c as a
plugin...

Regards.

PS. I surely don't want to start a useless flamewar...
-- 
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 mine, sont seulement les miennes} ***