Mercurial > hg > CbC > CbC_gcc

comparison gcc/doc/generic.texi @ 0:a06113de4d67

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
first commit
author kent <kent@cr.ie.u-ryukyu.ac.jp>
date Fri, 17 Jul 2009 14:47:48 +0900
parents
children b7f97abdc517
comparison
equal deleted inserted replaced
-1:000000000000 0:a06113de4d67
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}.