Basic file definitions

 

Since all the phases are kept in the PIPS library, a new phase $p$ needs a new directory $d$ in $PIPS_DIR/Development/Libs or at least should be put in an old one $d$. The generic structure of a PIPS source directory and a library in particular contains a config.makefile, a $d$-local.h file and various source files.

A phase $p$ itself is a function compatible with the C declaration of Figure 4. Thus if one wants to write a new phase in another language such as Fortran or Common Lisp, a C wrapping function should be used to call the phase kernel itself in this particular language and return the success flag. A phase returns false when it fails and PIPSMAKE stops executing the various phases .

The config.makefile is aimed to derive a read-only GNU Makefile through the PIPS make file generator pips-makemake that will be used to compile the sources in the directory $d$ to build a library lib$d$.a that will be linked later with other parts of PIPS to have a working executable. Many PIPS -specific generic rules are generated by pips-makemake (for C, Fortran, lex and yacc files, HTML and LaTeX documentation, various binary architectures, etc) and often the config.makefile is quite short, typically declaring the source files to use.

In the same way, a local include file $d$-local.h is used by the Makefile to generate a file $d$.h that declares all the functions and variables to be known from outside to use the $d$ library. $d$.h is the concatenation of $d$-local.h and all the non-static objects of the local C files extracted by cproto.

To sum up the directory creation and declaration for a new phase :

1. create the directory $d$ if necessary;
2. declare the list of the useful files in a config.makefile;
3. run pips-makemake ;
4. write a $p$ function that does the phase job;
5. run GNU make
6. debug it and iterate on previous points, eventually by doing a local pass as described later;
7. once the previous code has been compiled, the library is ready to be added to PIPS with editing the file $PIPS_DIR/Development/Scripts/dev/define_libraries.sh and typing make install.

  
Figure: Basic phase interface

In fact, the last points are a little bit interleaved since it rather hard to debug a new or modified phase without installing it, but it is dangerous to install some unstable code. For that purpose, there exist the rules test, ttest and wtest to locally build the passes pips , tpips and wpips respectively by linking with the local library instead of the one installed in the production version $PIPS_ROOT/Lib. Since often several libraries are co-developed and need to be linked together to be debugged, one can add all the other library $d\text{'}$ by doing a ln -s ../$d\text{'}$/lib$d\text{'}$.a.

In our case, we want to add a dead code elimination phase that is a transformation. Since there are many transformations with a rather small code, these are put all together in the transformations library. Since this library already exists, it is useless to create a new transformations directory in $PIPS_DEVEDIR/Libs. Just create the file dead_code_elimination.c and add its name in the LIB_CFILES of the config.makefile for the file to be considered when building the library.

Our dead code elimination has no reason to fail since we only apply legal optimization if necessary, thus the suppress_dead_code() function always returns TRUE , as we will see on Figure 6.