The purpose of GENERIC is simply to provide a
language-independent way of representing an entire function in
trees. To this end, it was necessary to add a few new tree codes
to the back end, but almost everything was already there. If you
can express it with the codes in gcc/tree.def
, it’s
GENERIC.
Early on, there was a great deal of debate about how to think
about statements in a tree IL. In GENERIC, a statement is
defined as any expression whose value, if any, is ignored. A
statement will always have TREE_SIDE_EFFECTS
set (or it
will be discarded), but a non-statement expression may also have
side effects. A CALL_EXPR
, for instance.
It would be possible for some local optimizations to work on the
GENERIC form of a function; indeed, the adapted tree inliner
works fine on GENERIC, but the current compiler performs inlining
after lowering to GIMPLE (a restricted form described in the next
section). Indeed, currently the frontends perform this lowering
before handing off to tree_rest_of_compilation
, but this
seems inelegant.
• Deficiencies: | Topics net yet covered in this document. | |
• Tree overview: | All about tree s.
| |
• Types: | Fundamental and aggregate types. | |
• Declarations: | Type declarations and variables. | |
• Attributes: | Declaration and type attributes. | |
• Expressions: | Operating on data. | |
• Statements: | Control flow and related trees. | |
• Functions: | Function bodies, linkage, and other aspects. | |
• Language-dependent trees: | Topics and trees specific to language front ends. | |
• C and C++ Trees: | Trees specific to C and C++. |