0
|
1 @c Copyright (c) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
|
|
2 @c Free Software Foundation, Inc.
|
|
3 @c This is part of the GCC manual.
|
|
4 @c For copying conditions, see the file gcc.texi.
|
|
5
|
|
6 @c ---------------------------------------------------------------------
|
|
7 @c GENERIC
|
|
8 @c ---------------------------------------------------------------------
|
|
9
|
|
10 @node GENERIC
|
|
11 @chapter GENERIC
|
|
12 @cindex GENERIC
|
|
13
|
|
14 The purpose of GENERIC is simply to provide a
|
|
15 language-independent way of representing an entire function in
|
|
16 trees. To this end, it was necessary to add a few new tree codes
|
|
17 to the back end, but most everything was already there. If you
|
|
18 can express it with the codes in @code{gcc/tree.def}, it's
|
|
19 GENERIC@.
|
|
20
|
|
21 Early on, there was a great deal of debate about how to think
|
|
22 about statements in a tree IL@. In GENERIC, a statement is
|
|
23 defined as any expression whose value, if any, is ignored. A
|
|
24 statement will always have @code{TREE_SIDE_EFFECTS} set (or it
|
|
25 will be discarded), but a non-statement expression may also have
|
|
26 side effects. A @code{CALL_EXPR}, for instance.
|
|
27
|
|
28 It would be possible for some local optimizations to work on the
|
|
29 GENERIC form of a function; indeed, the adapted tree inliner
|
|
30 works fine on GENERIC, but the current compiler performs inlining
|
|
31 after lowering to GIMPLE (a restricted form described in the next
|
|
32 section). Indeed, currently the frontends perform this lowering
|
|
33 before handing off to @code{tree_rest_of_compilation}, but this
|
|
34 seems inelegant.
|
|
35
|
|
36 If necessary, a front end can use some language-dependent tree
|
|
37 codes in its GENERIC representation, so long as it provides a
|
|
38 hook for converting them to GIMPLE and doesn't expect them to
|
|
39 work with any (hypothetical) optimizers that run before the
|
|
40 conversion to GIMPLE@. The intermediate representation used while
|
|
41 parsing C and C++ looks very little like GENERIC, but the C and
|
|
42 C++ gimplifier hooks are perfectly happy to take it as input and
|
|
43 spit out GIMPLE@.
|
|
44
|
|
45 @menu
|
|
46 * Statements::
|
|
47 @end menu
|
|
48
|
|
49 @node Statements
|
|
50 @section Statements
|
|
51 @cindex Statements
|
|
52
|
|
53 Most statements in GIMPLE are assignment statements, represented by
|
|
54 @code{GIMPLE_ASSIGN}. No other C expressions can appear at statement level;
|
|
55 a reference to a volatile object is converted into a
|
|
56 @code{GIMPLE_ASSIGN}.
|
|
57
|
|
58 There are also several varieties of complex statements.
|
|
59
|
|
60 @menu
|
|
61 * Blocks::
|
|
62 * Statement Sequences::
|
|
63 * Empty Statements::
|
|
64 * Jumps::
|
|
65 * Cleanups::
|
|
66 @end menu
|
|
67
|
|
68 @node Blocks
|
|
69 @subsection Blocks
|
|
70 @cindex Blocks
|
|
71
|
|
72 Block scopes and the variables they declare in GENERIC are
|
|
73 expressed using the @code{BIND_EXPR} code, which in previous
|
|
74 versions of GCC was primarily used for the C statement-expression
|
|
75 extension.
|
|
76
|
|
77 Variables in a block are collected into @code{BIND_EXPR_VARS} in
|
|
78 declaration order. Any runtime initialization is moved out of
|
|
79 @code{DECL_INITIAL} and into a statement in the controlled block.
|
|
80 When gimplifying from C or C++, this initialization replaces the
|
|
81 @code{DECL_STMT}.
|
|
82
|
|
83 Variable-length arrays (VLAs) complicate this process, as their
|
|
84 size often refers to variables initialized earlier in the block.
|
|
85 To handle this, we currently split the block at that point, and
|
|
86 move the VLA into a new, inner @code{BIND_EXPR}. This strategy
|
|
87 may change in the future.
|
|
88
|
|
89 A C++ program will usually contain more @code{BIND_EXPR}s than
|
|
90 there are syntactic blocks in the source code, since several C++
|
|
91 constructs have implicit scopes associated with them. On the
|
|
92 other hand, although the C++ front end uses pseudo-scopes to
|
|
93 handle cleanups for objects with destructors, these don't
|
|
94 translate into the GIMPLE form; multiple declarations at the same
|
|
95 level use the same @code{BIND_EXPR}.
|
|
96
|
|
97 @node Statement Sequences
|
|
98 @subsection Statement Sequences
|
|
99 @cindex Statement Sequences
|
|
100
|
|
101 Multiple statements at the same nesting level are collected into
|
|
102 a @code{STATEMENT_LIST}. Statement lists are modified and
|
|
103 traversed using the interface in @samp{tree-iterator.h}.
|
|
104
|
|
105 @node Empty Statements
|
|
106 @subsection Empty Statements
|
|
107 @cindex Empty Statements
|
|
108
|
|
109 Whenever possible, statements with no effect are discarded. But
|
|
110 if they are nested within another construct which cannot be
|
|
111 discarded for some reason, they are instead replaced with an
|
|
112 empty statement, generated by @code{build_empty_stmt}.
|
|
113 Initially, all empty statements were shared, after the pattern of
|
|
114 the Java front end, but this caused a lot of trouble in practice.
|
|
115
|
|
116 An empty statement is represented as @code{(void)0}.
|
|
117
|
|
118 @node Jumps
|
|
119 @subsection Jumps
|
|
120 @cindex Jumps
|
|
121
|
|
122 Other jumps are expressed by either @code{GOTO_EXPR} or
|
|
123 @code{RETURN_EXPR}.
|
|
124
|
|
125 The operand of a @code{GOTO_EXPR} must be either a label or a
|
|
126 variable containing the address to jump to.
|
|
127
|
|
128 The operand of a @code{RETURN_EXPR} is either @code{NULL_TREE},
|
|
129 @code{RESULT_DECL}, or a @code{MODIFY_EXPR} which sets the return
|
|
130 value. It would be nice to move the @code{MODIFY_EXPR} into a
|
|
131 separate statement, but the special return semantics in
|
|
132 @code{expand_return} make that difficult. It may still happen in
|
|
133 the future, perhaps by moving most of that logic into
|
|
134 @code{expand_assignment}.
|
|
135
|
|
136 @node Cleanups
|
|
137 @subsection Cleanups
|
|
138 @cindex Cleanups
|
|
139
|
|
140 Destructors for local C++ objects and similar dynamic cleanups are
|
|
141 represented in GIMPLE by a @code{TRY_FINALLY_EXPR}.
|
|
142 @code{TRY_FINALLY_EXPR} has two operands, both of which are a sequence
|
|
143 of statements to execute. The first sequence is executed. When it
|
|
144 completes the second sequence is executed.
|
|
145
|
|
146 The first sequence may complete in the following ways:
|
|
147
|
|
148 @enumerate
|
|
149
|
|
150 @item Execute the last statement in the sequence and fall off the
|
|
151 end.
|
|
152
|
|
153 @item Execute a goto statement (@code{GOTO_EXPR}) to an ordinary
|
|
154 label outside the sequence.
|
|
155
|
|
156 @item Execute a return statement (@code{RETURN_EXPR}).
|
|
157
|
|
158 @item Throw an exception. This is currently not explicitly represented in
|
|
159 GIMPLE.
|
|
160
|
|
161 @end enumerate
|
|
162
|
|
163 The second sequence is not executed if the first sequence completes by
|
|
164 calling @code{setjmp} or @code{exit} or any other function that does
|
|
165 not return. The second sequence is also not executed if the first
|
|
166 sequence completes via a non-local goto or a computed goto (in general
|
|
167 the compiler does not know whether such a goto statement exits the
|
|
168 first sequence or not, so we assume that it doesn't).
|
|
169
|
|
170 After the second sequence is executed, if it completes normally by
|
|
171 falling off the end, execution continues wherever the first sequence
|
|
172 would have continued, by falling off the end, or doing a goto, etc.
|
|
173
|
|
174 @code{TRY_FINALLY_EXPR} complicates the flow graph, since the cleanup
|
|
175 needs to appear on every edge out of the controlled block; this
|
|
176 reduces the freedom to move code across these edges. Therefore, the
|
|
177 EH lowering pass which runs before most of the optimization passes
|
|
178 eliminates these expressions by explicitly adding the cleanup to each
|
|
179 edge. Rethrowing the exception is represented using @code{RESX_EXPR}.
|