Jump to: navigation, search
Navigation: > CTools > ICI


Key concepts of the ICI

Current production compilers have fixed and black-box optimization heuristics without the means to to fine-tune the application of transformations. Interactive Compilation Interface (ICI) opens a compiler and provides opportunities for external control and examination of its optimization decisions with minimal changes. To avoid the pitfall of revealing all the compiler intermediate representation and libraries to a point where it would rigidify the whole internals and stiffen further evolution, we choose to control decision process itself, granting access to the only high-level features needed to effectively take a decision. Optimization settings at a fine-grained level, beyond the capabilities of command line options or pragmas, can be managed through external shared libraries, leaving the compiler uncluttered. ICI transform compilers into powerful research infrastructure where users could write their own program optimization and analysis plugins.


The Interactive Compilation Interface (or 'ICI', for short) is organized around four key concepts which together form an abstraction of programs and the compilation process:

  • plugins,
  • events,
  • features,
  • parameters.

The ICI framework acts as a "middleware" interface between the compiler and the user-definable plugins. Therefore, it offers two complementary views:

  • the plugin, or public view, exposing an abstraction of both the program being compiled and the compiler itself,
  • the compiler, or private view, exposing the interaction between the inner structure of the compiler and the abstract model presented to the user.

This explains a certain asymmetry of the API: certain operations are mainly performed from the compiler perspective (e.g., creation of events/parameters, triggering of events), while others are carried out by the plugins (definition and execution of callbacks, modification of parameters etc.)

[Need some way of indicating clearly which API functions are in the "compiler" (i.e., "private") part of the interface. The sole fact of being declared in "gcc/ic-private.h" is not enough.]


ICI plugins are dynamically loadable modules containing user-defined controls for the compiler.

The plugin programming interface consists of three kinds of functions:

  • initialisation function void start(void), in charge a.o. of registering event handlers,
  • termination function void stop(void), in charge of cleaning up the plugin data structures, closing files, etc.
  • event handler (callback) functions, which perform the actual work during plugin activity.


Events in ICI correspond to specific points in the execution of the compiler. Whenever the execution of the compiler reaches such a distinguished point, the ICI engine offers the possibility of immediately executing a user-definable callback function, or event handler.

The event structure (see gcc/ic-events.h) simply associates an event name and the corresponding event handler (callback):

/* Event structure.  */
struct event {
  const char *name;   /* Name for the event */
  event_func run;     /* Callback function */

Please note that currently, only a single handler can be associated with an event.
[It might be useful to support chains of handlers associated with a single event, but this will require a clearly defined prioritisation/ordering policy.]

Event handlers are parameter- and result-less functions of type event_func, declared in file gcc/ic-events.h as:

typedef void (*event_func) (void);


Features are abstractions of selected properties of the input program or the currect compiler state. They range from simple informations such as the name of the current function to the values of compiler parameters to the pass ordering in the current run of the compiler.

Features are represented as 4-tuples consisting of a name, a type (indicating if the feature is an informational one, or one relevant for machine learning), a data field and a callback function for dynamic extraction of feature values. The complete declaration (cf. file "gcc/ic-features.h") is:

#define FEATURE_ML   (1 << 0)
#define FEATURE_INFO (1 << 1)

/* Feature structure */
struct feature {
  const char *name;                 /* Feature name */
  int type;                         /* type for now FEATURE_ML | FEATURE_INFO */
  void *data;                       /* Pointer for static feature (void *) */
  const void * (*callback) (void);  /* Callback to dynamic feature function */

N.B.: when querying the value of a feature, the data field takes precedence over the callback: if the data field is non-NULL, it is directly returned, and the callback is called only when data field is NULL. This behaviour can be overridden by calling the callback function directly. [FIXME: There should be an additional function to get the dynamic value of the feature, ignoring the data field.]

[more info about ML features needed here].


ICI parameters are abstractions of compiler variables and variable expressions. They are identified by textual names (strings) and are the main representation of compiler state visible to event handlers, serving as a decoupling mechanism betwween plugins and the actual implementations of compiler internals.

The representation of parameters, defined in file gcc/ic-events.h, is very simple:

/* Parameter structure.  */
struct parameter {
  const char *name;   /* Name for the parameter */
  const void *value;  /* Pointer to data */

A parameter can be used to get and/or set the value of the corresponding expression in the compiler.

Locations of visitors to this page