There are a large number of kinds of tree structured or tree-like data in CPROVER.
More...
There are a large number of kinds of tree structured or tree-like data in CPROVER.
irept provides a single, unified representation for all of these, allowing structure sharing and reference counting of data. As such irept is the basic unit of data in CPROVER. Each irept contains (or references, if reference counted data sharing is enabled, as it is by default - see the SHARING macro) to a node (see tree_nodet). The irept::pretty function outputs the explicit tree structure of an irept and can be used to understand and debug problems with irepts.
On their own irepts do not "mean" anything; they are effectively generic tree nodes. Their interpretation depends on the contents of result of the id() function, i.e. the data field. util/irep_ids.def contains a list of id values. During the build process it is used to generate util/irep_ids.h which gives constants for each id (named ID_). You can also make irep_idts which do not come from util/irep_ids.def. An irep_idt can then be used to identify what kind of data the irept stores and thus what can be done with it.
To simplify this process, there are a variety of classes that inherit from irept, roughly corresponding to the ids listed (i.e. ID_or (the string "or”) corresponds to the class \ref or_exprt). These give
semantically relevant accessor functions for the data; effectively
different APIs for the same underlying data structure. None of these
classes add fields (only methods) and so static casting can be used. The
inheritance graph of the subclasses of \ref irept is a useful starting
point for working out how to manipulate data.
There are three main groups of classes (or APIs); those derived from
\ref typet, \ref codet and \ref exprt respectively. Although all of these
inherit from \ref irept, these are the most abstract level that code should
handle data. If code is manipulating plain <tt>irept</tt>s then something is wrong
with the architecture of the code.
Many of the key descendants of \ref exprt are declared in \ref std_expr.h.
All expressions have a named subexpression with ID "type", which gives the type of the expression (slightly simplified from C/C++ as unsignedbv_typet, signedbv_typet, floatbv_typet, etc.). All type conversions are explicit with a typecast_exprt. One key descendant of exprt is symbol_exprt which creates irept instances with ID “symbol”. These are used to represent variables; the name of which can be found using the get_identifier accessor function.
codet inherits from exprt and is defined in std_code.h. It represents executable code; statements in a C-like language rather than expressions. In the front-end there are versions of these that hold whole code blocks, but in goto-programs these have been flattened so that each irept represents one sequence point (almost one line of code / one semi-colon). The most common descendant of codet is code_assignt so a common pattern is to cast the codet to an assignment and then recurse on the expression on either side.
Definition at line 351 of file irep.h.
Inheritance diagram for irept:
1.9.8