Statement Sequences. GNU GCC

Chapter 9: Analysis and Optimization of GIMPLE Trees 93

9.2.4.2 Statement Sequences

Multiple statements at the same nesting level are collected into a STATEMENT_LIST. Statement lists are modified and traversed using the interface in ‘tree-iterator.h’.

9.2.4.3 Empty Statements

Whenever possible, statements with no effect are discarded. But if they are nested within another construct which cannot be discarded for some reason, they are instead replaced with an empty statement, generated by build_empty_stmt. Initially, all empty statements were shared, after the pattern of the Java front end, but this caused a lot of trouble in practice.

An empty statement is represented as (void)0.

9.2.4.4 Loops

At one time loops were expressed in GIMPLE using LOOP_EXPR, but now they are lowered to explicit gotos.

9.2.4.5 Selection Statements

A simple selection statement, such as the C if statement, is expressed in GIMPLE using a void COND_EXPR. If only one branch is used, the other is filled with an empty statement.

Normally, the condition expression is reduced to a simple comparison. If it is a shortcut

(&& or ||) expression, however, we try to break up the if into multiple ifs so that the implied shortcut is taken directly, much like the transformation done by do_jump in the

RTL expander.

A SWITCH_EXPR in GIMPLE contains the condition and a TREE_VEC of CASE_LABEL_EXPRs describing the case values and corresponding LABEL_DECLs to jump to. The body of the switch is moved after the SWITCH_EXPR.

9.2.4.6 Jumps

Other jumps are expressed by either GOTO_EXPR or RETURN_EXPR.

The operand of a GOTO_EXPR must be either a label or a variable containing the address to jump to.

The operand of a RETURN_EXPR is either NULL_TREE or a MODIFY_EXPR which sets the return value. It would be nice to move the MODIFY_EXPR into a separate statement, but the special return semantics in expand_return make that difficult. It may still happen in the future, perhaps by moving most of that logic into expand_assignment.

9.2.4.7 Cleanups

Destructors for local C++ objects and similar dynamic cleanups are represented in GIMPLE by a TRY_FINALLY_EXPR. When the controlled block exits, the cleanup is run.

TRY_FINALLY_EXPR complicates the flow graph, since the cleanup needs to appear on every edge out of the controlled block; this reduces the freedom to move code across these edges. Therefore, the EH lowering pass which runs before most of the optimization passes eliminates these expressions by explicitly adding the cleanup to each edge.