The CPPC Project

Some of the transforms implemented by the CPPC compiler are semantic-directed. These require certain semantic information about which function calls implement certain semantics and how. Since source code in imperative languages is not intrinsically semantic, it is necessary to provide semantic information to the compiler. The mechanism for supplying this information is extensible and not tied to specific implementations of a semantic, fulfilling the portability target present in CPPC.

The compiler reads this semantic information from XML files having a given, simple format. Take a look at the "linux-module.xml" in the "compiler/semantic-meta" subdirectory. Each of this files is called a "semantic module", and contains semantic information about a collection of related procedures. Each procedure can have any number of semantic tags, each one of them having a "role" identifier and, optionally, a number of attributes that give further information on how the procedure implements the given semantic.

Look, for example, at the UNIX fopen and open functions. Both accept two parameters: a path string and modifiers on how to open the file, and both return a reference to the opened file. This information is passed to the compiler in the semantic description of the functions. This reference is different for each one of them, a FILE * for the fopen function and an integer for open. The given "DescriptorType" attribute tells the compiler which type of file descriptor does the function return.

Besides semantic information, these files also contain data flow information. The input, output and input-output parameter tags contain information about the outcome, in terms of data flow, of the call to a certain procedure. This is useful for optimizing the amount of information saved to disk by providing some information about opaque function calls to the data flow analyses.

The current release of CPPC includes semantic modules for common POSIX functions, MPI, and common Fortran intrinsics. If you intend to provide support for a specific family of functions not included with CPPC, follow these steps:

1. Create a new XML file, and insert the necessary <cppc-semantic-module > and <module> tags. Give the module a name that fits the function family which documents.
2. Add the functions in that family (or simply the ones you need). For each function, add a classification of its parameters in terms of data flow: input/output/input-output. Note that you do not strictly need to add this information, but it will improve the efficiency of the checkpointing process.
3. Add the semantic roles to the relevant functions. Current recognized roles are:
   • CPPC/Nonportable: Identifies a procedure as having a non portable outcome, which has to be recovered by code re-execution rather than by storing it into the save file.
   • CPPC/IO/Open and CPPC/IO/Close: For marking functions that open/close sequential access streams. It is required if you want CPPC to automatically track the state of such media. Attributes for the semantic role are the "Path" to the file being opened, the "FileDescriptor" being returned and its "DescriptorType". You can see an example in the semantic modules bundled with this distribution.
   • CPPC/Comm/Initializer: Used for identifying functions that initialize the parallel system. Since CPPC might perform interprocess communications at restart time, it needs to locate the point in the code where the comm system is started.
   • CPPC/Comm/Ranker: Used for identifying functions that return the rank of a parallel process. It is necessary to correctly perform the communications analysis.
   • CPPC/Comm/Sizer: Used for identifying functions that return the size of a communicator in a parallel execution. It is necessary to correctly perform the communications analysis.
4. If your semantic module documents a widely used family of functions, please send it to the contact address shown in the main page so that it can be added to the next version of the CPPC compiler.