Together with the computer architectural evolution, three main directions in compiler developments have been pursued: compilers for sequential machines (with superscalar processors), parallelizers of sequential programs and compilers for explicit parallel programs. All these approaches benefit from deep global program analyses, such as interprocedural and semantical analyses, to perform optimizations, vectorization, parallelization, transformations, restructuring and reverse-engineering of programs. Since these approaches often require the same or share a common ground of analyses, it is interesting to factorise them out in a common development tool to get the benefit of code re-use and modular programming.
PIPS is such a highly modular workbench for implementing and assessing various interprocedural compilers, optimizers, parallelizers, vectorizers, restructurers, etc. without having to build a new compiler from scratch. It has been used in various compilation areas since its inception in 1988 as the PIPS project (Interprocedural Parallelization of Scientific Programs).
This project aims at combining advanced interprocedural and semantical analyses [10] with a requirement for compilation speed. The mathematical foundations of the semantical analysis implemented in PIPS are linear programming and polyhedra theory. Despite such advanced techniques, PIPS is able to deal with real-life programs such as benchmarks provided by ONERA (French research institute in aeronautics), or the Perfect Club in quite reasonable time.
PIPS is a source to source and multi-target parallelizer. It incorporates many code transformations and options to tune its features and phases. PIPS offers interesting solutions to solve programming design problems such as generating high-level data structures from specifications, co-generating their documentation, defining user interface description and configuration files, dealing with object persistence and resource dependences, being able to write parts of PIPS in various languages, etc.
This paper details how to deal with some of these features to add a new phase in PIPS and a dead code elimination phase will serve as a running example through out the paper. Such a description could seem somewhat cumbersome but it gives an idea of how the PIPS features are organized for people wanting to use PIPS as a compiler development tool since it is publicly available.
We first present the general design of PIPS in Section 2. In Section 3 we sketch a dead code elimination phase and we explain how it is added to PIPS in Section 4.