From a theoretical point of view, the object types and functions available in PIPS define an heterogeneous algebra with constructors (e.g. parsers), extractors (e.g. pretty-printers) and operators (e.g. loop unrolling and other transformations). Very few combinations of functions make sense, but many functions and object types are available. This abundance is confusing for casual and even experienced users and it was deemed necessary to assist them by providing default computation rules and automatic consistency management.
Figure 5: Example of pipsmake-rc rules.
The PIPSMAKE library - not so far from the Unix make utility - is the corner stone of PIPS interprocedurality. The objects it manages are resources stored in memory or/and on disk. The phases are described in a pipsmake-rc file by generic rules that use and produce resources. The ordering of the computation is demand-driven, dynamically and automatically deduced from the pipsmake-rc specification file.
In our dead code elimination example, we need the code of the current module of course, but also its preconditions and its proper effects for the semantical information. The entities of all the program are also needed to have access to variables, COMMONs and so on. The global effect of this transformation is to rewrite the code of the current module. These dependences are abstracted by the pipsmake-rc syntax on Figure 5.
For each rule, that is in fact the textual name of a phase C function, it is possible to add a list of constraints composed with a qualifier, an owner name and a resource name. Each constraint has the following syntax: [ <qualifyer> ; <owner-name>.<resource-name> ]
The qualifier describs how the resource can be used: < for needed, > generated, # destroyed by the rule, = asserts that the resource remains valid even if other dependence rules would suggest to invalidate the resource, ! asks for applying another rule before executing the rule.
An owner name specifies the owner of the needed resource. For example for the code resource, only the code of this module, or the code of all the modules, etc. Two interesting owners are CALLEES (the set of modules called by the current one, used to describe bottom-up analyses on the call-graph) and CALLERS (the set of modules calling the current one that can expresses top-down analyses). They are the mechanism that deals with interprocedurality in PIPS . In our small example, the interprocedurality is not highlighted because if the dead code elimination uses interprocedural information (the preconditions and the effects), it is not interprocedural per se.
An API is available for advanced usage to call PIPSMAKE directly to build a resource inside a user interface for example.