MELT is a Lispy like domain specific language to extend GCC. See
http://gcc-melt.org/ ; you'll be able to extend or customize the GCC
compiler in MELT easier than you would code some C++ plugin, thanks to the
high-level features of MELT: pattern matching, functional, reflexive,
object-oriented programming styles with meta-programming facilities.
MELT is translated to C++ code (by a translator itself coded in MELT).
You can mix C++ code inside MELT.
MELT can also be used to explore the GCC (mostly middle-end) internal
representations notably Gimple-s and Tree-s. With MELT you can for
example, with a few arguments to gcc, find all calls to malloc with a
constant size greater than 100 (and you need to do that *inside* the
compiler, because that size could be constant folded and using sizeof
etc....).
Thanks to (in alphabetical order) Romain Geissler, Emmanuel Haucourt,
Alexandre Lissy, Jérémie Salvucci, Pierre Vittet for their
contributions to GCC MELT, and to the DGCIS French funding agency for
having funded my work at CEA LIST (www-list.cea.fr)
##################################################################
Short installation instructions for MELT as a plugin to an installed
gcc-4.7 or gcc-4.8 (or future gcc-4.9) enabled for plugins.
See also http://gcc-melt.org/
MELT is a plugin and domain specific language for extending GCC (the
Gnu Compiler Collection), free software GPLv3+ licensed, FSF
copyrighted. MELT is a lispy, high-level, language providing pattern
matching and enabling functional/applicative/reflective programming
styles, to ease development of GCC extensions. MELT is translated to
C code (and the MELT translator is implemented in MELT).
If installing MELT as plugin to some existing gcc-4.7 installation
tree, with the support of plugins enabled (or replace 4.7 by 4.8 if
relevant):
################ quick steps for Debian/Unstable or Ubuntu or derived distributions ####
## Run as root (e.g. with sudo):
apt-get install gcc-4.7 g++-4.7 make texinfo texi2html autogen gawk
apt-get build-dep gcc-4.7
apt-get install libppl-dev libppl-c-dev gcc-4.7-plugin-dev
## then retrieve the MELT plugin release, and cd into it, then
make all
make install DESTDIR=/tmp/meltinstall
## You might explicit the compiler you want to extend and to use:
make all CC=/usr/bin/gcc-4.7 CXX=/usr/bin/g++-4.7
make install CC=/usr/bin/gcc-4.7 CXX=/usr/bin/g++-4.7 DESTDIR=/tmp/meltinstall
## The first "make all" needs 15 minutes, less than 1Gb disk, 4Gb RAM, and
## *cannot be* a parallel "make -j all"
## finally, as root copy the destination to install MELT
cp -v -p -R /tmp/meltinstall/. /.
## Since MELT may generate and compile C code on the fly, you'll need its build
## dependencies even to run it..
## You need to rebuild & reinstall MELT even for minor GCC release
## upgrades (ie. from GCC 4.7.2 to 4.7.3).
#########################################################################
################################################################ DETAILS
################ step 1
First, ensure that 4.7 or 4.8 is correctly installed and has been built
with plugins enabled, for example (on a Debian Unstable, package gcc-4.8):
% gcc-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Debian 4.8.1-3)
Be sure that you have all the development packages for all libraries
used by GCC (e.g. run 'apt-get build-dep gcc' on Debian). In
particular, you'll need the headers of CLOOG, PPL, MPC, MPFR, GMP
libraries.
Ensure that your system have recent autogen, GNU make, gawk (GNU awk), texinfo,
texi2html utilities
################ step 2
Then, be sure that the GCC plugin development support has been
installed. (On Debian, you'll need e.g. the gcc-4.8-plugin-dev package).
So you should have something like
% gcc-4.8 -print-file-name=plugin
/usr/lib/gcc/x86_64-linux-gnu/4.8/plugin
Be sure that this plugin subdirectory is populated correctly since it
contains an include directory and probably a gengtype executable (and
perhaps more, e.g. your previous installation of MELT).
% ls -l $(gcc-4.8 -print-file-name=plugin)
-rwxr-xr-x 1 root root 172160 Sep 5 00:01 gengtype
-rw-r--r-- 1 root root 554675 Sep 4 23:47 gtype.state
drwxr-xr-x 9 root root 20480 Sep 11 09:24 include
Nota Bene: the gtype.state and gengtype files might perhaps be elsewhere.
Be sure that this include subdirectory contains meaningful files for
GCC, like those for GIMPLE
% ls -l $(gcc-4.8 -print-file-name=plugin)/include/gimple.*
-rw-r--r-- 1 root root 14409 Sep 4 23:48 /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/gimple.def
-rw-r--r-- 1 root root 134641 Sep 4 23:48 /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/gimple.h
-rw-r--r-- 1 root root 1368 Sep 4 23:48 /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/gimple-pretty-print.h
Be sure that the gengtype executable and its gtype.state textual data
file is available somewhere. On Debian/Sid the package
gcc-4.8-plugin-dev provides them
If you have some previous MELT related files and directories it is
preferable but not necessary to remove them. You might have two different
releases of MELT for the same compiler but we don't recommend doing that.
rm -rf $(gcc-4.8 -print-file-name=plugin)/*melt*
Look with an editor, or just with the head command, that this gtype.state
file is indeed the one related to your gcc-4.8:
% head /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/gtype.state
;;;;@@@@ GCC gengtype state
;;; DON'T EDIT THIS FILE, since generated by GCC's gengtype
;;; The format of this file is tied to a particular version of GCC.
;;; Don't parse this file wihout knowing GCC gengtype internals.
;;; This file should be parsed by the same gengtype which wrote it.
(!version "4.8.1")
(!srcdir "../../src/gcc")
################ step 3
Your plugin MELT directory should contain a Makefile which is a
symlink to a MELT-Plugin-Makefile file. Please look into that file.
(Most of the work is done in melt-build.mk, included from it).
Use
make all
to build the MELT plugin which takes some time (15 minutes), because MELT is
retranslating itself. It cannot be a parallel make -j
Use
make install DESTDIR=/tmp/meltinstall
to install the MELT plugin. The usual DESTDIR behave as expected.
As root, copy it appropriately:
cp -v -R -p /tmp/meltinstall/. /.
Actually, only /usr is affected on many Linux distributions,
so that could have been
cp -v -R -p /tmp/meltinstall/usr/. /usr/.
#### uninstallation
Since all MELT related files are installed under
$(gcc-4.8 -print-file-name=plugin) you can just do as root
rm -v -r -f $(gcc-4.8 -print-file-name=plugin)/*melt*
to uninstall MELT
########## For packagers
Notice that the MELT plugin should be entirely rebuilt
even for small changes of the compiler (e.g. when upgrading gcc from
4.8.1 to 4.8.2).
################
To prepare a source tree of the MELT plugin from the GCC MELT branch,
run contrib/gcc_update then read and run
contrib/make-melt-source-tar.sh from the GCC MELT branch. For
instance, I am running it with something similar to
/usr/src/Lang/gcc-melt-branch/contrib/make-melt-source-tar.sh \
/usr/src/Lang/gcc-melt-branch \
/tmp/gcc-melt-plugin
If all goes well, you get a /tmp/gcc-melt-plugin.tgz gnuzipped tar
archive for the MELT plugin. This is only needed to people making a
new MELT plugin source archive.
################
Comments about the MELT plugin (including its installation script) are
welcome by email to <basile@starynkevitch.net> [please mention MELT in
the subject line] and to <gcc-melt@googlegroups.com>
################################################################
NEWS for 1.0 MELT plugin for GCC 4.7 & 4.8 [and future 4.9?]
[[october 29th, 2013]]
This is a major release (with perhaps some small incompatibilities
with previous MELT plugin releases). A lot of new features are
appearing. Much more ability to mix arbitrary C/C++ & MELT code in any
way, and lots of new features both inside the MELT language and the
MELT plugin, even for newbies. Some modes are now available and could
be useful even without understanding much of the MELT domain specific
language.
MELT 1.0 is usable with GCC 4.7 and 4.8 but not usable with GCC 4.6 or
earlier, because it requires a GCC compiler written in C++ and because
it is generating C++ code.
End-user improvements
=====================
****
* Several MELT modes are usable without real knowledge of the MELT
domain specific language, notably -fplugin-arg-melt-mode=findgimple
(to find all gimples matching some given gimple pattern in all
functions whose declaration matches a given tree pattern) and
-fplugin-arg-melt-mode=justcountipa (to count gimples and basic
blocks at the Inter-Procedural Analysis stage).
Several examples of MELT modes are given in
http://gcc-melt.org/tutousemelt.html
It is notably possible to
+ find all calls to malloc with a constant size greater than 100
that size could have been given thru sizeof and/or some
constant expressions...
+ find all calls to printf with a format string containing the
word current and more than 6 arguments inside functions whose
name start with foo
+ etc....
These exploring modes have to work inside the compiler. A textual
approach won't work. So these exploring modes should interest a
large number of GCC users.
***
* When verbose, all the successful modes are displayed.
Language improvements
=====================
***
* It is possible to define macros with defmacro (taking four
arguments: the s-expression to be macro-expanded, the environment,
the macro-expander function, the module context). Such macros can be
used in the same MELT module defining them, but should expand to a
source AST which you would be able to read...
***
* It is possible to define locally bound macros with the :macro annotation
in let bindings.
***
* at_macro_expansion macro can be used to define functions (and
instances, etc...) used only at macro-expansion time of further
defmacro-defined macros.
***
* Macros defined by defmacro and definition given inside at_macro_expansion
are evaluated in a separate environment so don't see the ordinary bindings
currently defined in the MELT source.
***
* The comma operator, only usefine inside anti-quotations (thru
backquote) is expanded to a sequence of sub-expressions if the
anti-quotation gives a sequence, i.e. a tuple or a list. So no
comma-at operator is needed.
***
* quotes, anti-quotes (with backquote), and comma operators are
possible even on arbitrary s-expressions. But quotations and
antiquotations of s-exprs have their location slightly less precise
(only file name and line number, but not column number, are
preserved)
Runtime improvements
====================
***
* The debug macro accepts debug manipulator which alters the way
the next argument is debug-printed, e.g.
(DEBUG "here smaller debug of x=" DEBUG_LESS x)
***
* The variadic ERROR_AT WARNING_AT and INFORM_AT functions are available
for diagnostics. They take a format string with occurrences of $1 ... $9
expanded into variadic arguments. For example
(ERRROR_AT somelocation "this is an error with number $1 and tree $2"
somenumber sometree)
The location can be null, or be given by some boxed gimple or boxed tree.
***
* The ASSERT_MSG macro can have more arguments, which are shown
when the assertion fails.
***
* MELT registered passes have a unique number (for GCC 4.9).
***
* The runtime is named melt-runtime.cc since it is C++ code.
***
* MELT generated frames are classy because they are C++ classes.
As usual, many bug fixes... A ticket system is now available on
https://sourceforge.net/p/gcc-melt/tickets/ for bug reports.
################################################################
NEWS for 0.9.9 MELT plugin for GCC 4.6 & 4.7 & 4.8
[[june, 22nd, 2013]]
This is a significant release. A lot of new features are
appearing. Much more ability to mix arbitrary C/C++ & MELT code in any
way and both directions!
This is the last MELT release supporting GCC 4.6 and GCC compilers in
C only. Future MELT releases with will be C++ only (i.e. emit C++
code), for GCC 4.7 & 4.8
Language improvements
=====================
***
* Code chunks can contain void side-effecting expressions of :VOID
ctype, translated to some C/C++ block. Hence code chunks can even
be indirectly nested. Within the macro-string, write $(...) for
the expression. You may want to make it a PROGN ending with
(VOID) to force it to be void. Sub-expressions -of :VOID ctype-
inside code chunks are evaluated at the place of appearance, and
are expanded to C/C++ blocks at their occurrence.
***
* Expression chunks are expanded into C/C++ expressions. Syntax is
(EXPR_CHUNK <state-symbol> <ctype> <macro-string> ...)
For instance, to get the pid of the cc1 running your MELT extension, use
(expr_chunk getpid_chk :long #{/*$GETPID_CHK*/ (long)getpid()}#)
Important notice: any sub-expression appearing in some EXPR_CHUNK
is evaluated before, like for primitives, so will always be
evaluated.
***
* Ability to emit some C code in the implementation part. Syntax
(CIMPLEMENT <code-string>)
This is a companion to the existing CHEADER. Useful to declare some
specific non-inlined C++ function or static variable with CHEADER
and to define it with CIMPLEMENT.
***
* New ability to add module "static" value variables in MELT
(DEFVAR <varname>)
The so defined variable <varname> is (in the generated C/C++ code)
a pointer [to some MELT value] inside a static array. Garbage
collection support is generated. The variable <varname> cannot be
exported with EXPORT_VALUES, you need to export functions accessing
or changing it. Once defined, you can use SETQ to assign to such a
module variable (and also DEFHOOK with :VAR)
***
* New ability to define hooks, that is C/C++ functions coded in
MELT. Syntax is
(DEFHOOK <hookname> <input-formals> <output-formals> <ctype>
[:var <module-variable>] <body...>)
The optional <module-variable> given with a :var annotation should be
a module variable previously defined with DEFVAR.
For example, with the following code
(defvar varlist)
(setq varlist (list))
(defvar varhook)
(defhook appendnumhk (:long n) (:long outlen) :void
:var varhook
(list_append varlist (constant_box n))
(setq outlen (list_length varlist)))
you get two generated extern "C" functions in the emitted C/C++ code
void melthook_APPENDNUMHK (melt_ptr_t hook, long n, long* outlen);
and
void melthookproc_APPENDNUMHK (long n, long* outlen);
which you could use e.g. in some other code_chunk-s. The first
function melthook_APPENDNUMHK needs the hook value `appendnumhk' as
its first argument; the second function melthookproc_APPENDNUMHK
is generated because a :var annotation has been given, and uses
the hook value automagically stored in that `varhook' module
variable.
Many functions previously coded in C/C++ inside the melt-runtime.c
have been migrated to predefined hooks coded in MELT inside
melt/warmelt-hooks.melt etc...
Hooks are a very important addition: with them you can mix C/C++ & MELT code
at will.
***
* New ability to call hooks,
Expresssions can also call known hooks given by their operator. But
the hook cannot be unknown: only applications can be done with
statically unknown operators.
***
* EVAL function
An EVAL function has been added, it wraps the existing
TRANSLATE_RUN_MELT_EXPRESSIONS utility function so works by
generating C/C++ code then loading and running it.
Runtime improvements
====================
***
* To register your MELT pass, use the INSTALL_MELT_PASS_IN_GCC
function instead of the obsolete INSTALL_MELT_GCC_PASS
primitive. Notice that INSTALL_MELT_PASS_IN_GCC is incompatible
with the older INSTALL_MELT_GCC_PASS, because you need to pass
the :after keyword instead of the "after" cstring, etc, etc...
***
* Many plugin events are interfaced (using hook machinery).
Some of them are incompatible with previous MELT releases.
***
* Add macro melt_low_debug_value(Message,Value) to debug-print
some arbitrary MELT value in C/C++ code or chunk.
This goes thru a predefined hook, similar to the DEBUG macro of MELT.
***
* Add C variable melt_plugin_name containing the name of the MELT
plugin, useful for using register_callback.
***
* Raised default threshold for GC. The MELT full garbage
collector is less called.
***
* Many bug fixes and internal improvements... Emitted C/C++ code
contains more checks.. REPL and EVAL modes are working much better.
***
* More primitives and functions
################################################################
NEWS for earlier versions of MELT are available in the
README-MELT-PLUGIN file of the tarball.
october 29th 2013
################################################################
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} ***
