extend jump thread for finite state automata
[official-gcc.git] / gcc / doc / match-and-simplify.texi
blob2d8faf881fceaccd21506fcdfc07a5b658ac49e7
1 @c Copyright (C) 2014 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.
6 @node Match and Simplify
7 @chapter Match and Simplify
8 @cindex Match and Simplify
10 The GIMPLE and GENERIC pattern matching project match-and-simplify
11 tries to address several issues.
13 @enumerate
14 @item unify expression simplifications currently spread and duplicated
15     over separate files like fold-const.c, gimple-fold.c and builtins.c
16 @item allow for a cheap way to implement building and simplifying
17     non-trivial GIMPLE expressions, avoiding the need to go through
18     building and simplifying GENERIC via fold_buildN and then
19     gimplifying via force_gimple_operand
20 @end enumerate
22 To address these the project introduces a simple domain specific language
23 to write expression simplifications from which code targeting GIMPLE
24 and GENERIC is auto-generated.  The GENERIC variant follows the
25 fold_buildN API while for the GIMPLE variant and to address 2) new
26 APIs are introduced.
28 @menu
29 * GIMPLE API::
30 * The Language::
31 @end menu
33 @node GIMPLE API
34 @section GIMPLE API
35 @cindex GIMPLE API
37 @deftypefn {GIMPLE function} tree gimple_simplify (enum tree_code, tree, tree, gimple_seq *, tree (*)(tree))
38 @deftypefnx {GIMPLE function} tree gimple_simplify (enum tree_code, tree, tree, tree, gimple_seq *, tree (*)(tree))
39 @deftypefnx {GIMPLE function} tree gimple_simplify (enum tree_code, tree, tree, tree, tree, gimple_seq *, tree (*)(tree))
40 @deftypefnx {GIMPLE function} tree gimple_simplify (enum built_in_function, tree, tree, gimple_seq *, tree (*)(tree))
41 @deftypefnx {GIMPLE function} tree gimple_simplify (enum built_in_function, tree, tree, tree, gimple_seq *, tree (*)(tree))
42 @deftypefnx {GIMPLE function} tree gimple_simplify (enum built_in_function, tree, tree, tree, gimple_seq *, tree (*)(tree))
43 The main GIMPLE API entry to the expression simplifications mimicing
44 that of the GENERIC fold_@{unary,binary,ternary@} functions.
45 @end deftypefn
47 thus providing n-ary overloads for operation or function.  The
48 additional arguments are a gimple_seq where built statements are
49 inserted on (if @code{NULL} then simplifications requiring new statements
50 are not performed) and a valueization hook that can be used to
51 tie simplifications to a SSA lattice.
53 In addition to those APIs @code{fold_stmt} is overloaded with
54 a valueization hook:
56 @deftypefn bool fold_stmt (gimple_stmt_iterator *, tree (*)(tree));
57 @end deftypefn
60 Ontop of these a @code{fold_buildN}-like API for GIMPLE is introduced:
62 @deftypefn {GIMPLE function} tree gimple_build (gimple_seq *, location_t, enum tree_code, tree, tree, tree (*valueize) (tree) = NULL);
63 @deftypefnx {GIMPLE function} tree gimple_build (gimple_seq *, location_t, enum tree_code, tree, tree, tree, tree (*valueize) (tree) = NULL);
64 @deftypefnx {GIMPLE function} tree gimple_build (gimple_seq *, location_t, enum tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = NULL);
65 @deftypefnx {GIMPLE function} tree gimple_build (gimple_seq *, location_t, enum built_in_function, tree, tree, tree (*valueize) (tree) = NULL);
66 @deftypefnx {GIMPLE function} tree gimple_build (gimple_seq *, location_t, enum built_in_function, tree, tree, tree, tree (*valueize) (tree) = NULL);
67 @deftypefnx {GIMPLE function} tree gimple_convert (gimple_seq *, location_t, tree, tree);
68 @end deftypefn
70 which is supposed to replace @code{force_gimple_operand (fold_buildN (...), ...)}
71 and calls to @code{fold_convert}.  Overloads without the @code{location_t}
72 argument exist.  Built statements are inserted on the provided sequence
73 and simplification is performed using the optional valueization hook.
76 @node The Language
77 @section The Language
78 @cindex The Language
80 The language to write expression simplifications in resembles other
81 domain-specific languages GCC uses.  Thus it is lispy.  Lets start
82 with an example from the match.pd file:
84 @smallexample
85 (simplify
86   (bit_and @@0 integer_all_onesp)
87   @@0)
88 @end smallexample
90 This example contains all required parts of an expression simplification.
91 A simplification is wrapped inside a @code{(simplify ...)} expression.
92 That contains at least two operands - an expression that is matched
93 with the GIMPLE or GENERIC IL and a replacement expression that is
94 returned if the match was successful.
96 Expressions have an operator ID, @code{bit_and} in this case.  Expressions can
97 be lower-case tree codes with @code{_expr} stripped off or builtin
98 function code names in all-caps, like @code{BUILT_IN_SQRT}.
100 @code{@@n} denotes a so-called capture.  It captures the operand and lets
101 you refer to it in other places of the match-and-simplify.  In the
102 above example it is refered to in the replacement expression.  Captures
103 are @code{@@} followed by a number or an identifier.
105 @smallexample
106 (simplify
107   (bit_xor @@0 @@0)
108   @{ build_zero_cst (type); @})
109 @end smallexample
111 In this example @code{@@0} is mentioned twice which constrains the matched
112 expression to have two equal operands.  This example also introduces
113 operands written in C code.  These can be used in the expression
114 replacements and are supposed to evaluate to a tree node which has to
115 be a valid GIMPLE operand (so you cannot generate expressions in C code).
117 @smallexample
118 (simplify
119   (trunc_mod integer_zerop@@0 @@1)
120   (if (!integer_zerop (@@1)))
121   @@0)
122 @end smallexample
124 Here @code{@@0} captures the first operand of the trunc_mod expression
125 which is also predicated with @code{integer_zerop}.  Expression operands
126 may be either expressions, predicates or captures.  Captures
127 can be unconstrained or capture expresions or predicates.
129 This example introduces an optional operand of simplify,
130 the if-expression.  This condition is evaluated after the
131 expression matched in the IL and is required to evaluate to true
132 to enable the replacement expression.  The expression operand
133 of the @code{if} is a standard C expression which may contain references
134 to captures.
136 A @code{if} expression can be used to specify a common condition
137 for multiple simplify patterns, avoiding the need
138 to repeat that multiple times:
140 @smallexample
141 (if (!TYPE_SATURATING (type)
142      && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type))
143   (simplify
144     (minus (plus @@0 @@1) @@0)
145     @@1)
146   (simplify
147     (minus (minus @@0 @@1) @@0)
148     (negate @@1)))
149 @end smallexample
151 Ifs can be nested.
153 Captures can also be used for capturing results of sub-expressions.
155 @smallexample
156 #if GIMPLE
157 (simplify
158   (pointer_plus (addr@@2 @@0) INTEGER_CST_P@@1)
159   (if (is_gimple_min_invariant (@@2)))
160   @{
161     HOST_WIDE_INT off;
162     tree base = get_addr_base_and_unit_offset (@@0, &off);
163     off += tree_to_uhwi (@@1);
164     /* Now with that we should be able to simply write
165        (addr (mem_ref (addr @@base) (plus @@off @@1)))  */
166     build1 (ADDR_EXPR, type,
167             build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@@2)),
168                     build_fold_addr_expr (base),
169                     build_int_cst (ptr_type_node, off)));
170   @})
171 #endif
172 @end smallexample
174 In the above example, @code{@@2} captures the result of the expression
175 @code{(addr @@0)}.  For outermost expression only its type can be captured,
176 and the keyword @code{type} is reserved for this purpose.  The above
177 example also gives a way to conditionalize patterns to only apply
178 to @code{GIMPLE} or @code{GENERIC} by means of using the pre-defined
179 preprocessor macros @code{GIMPLE} and @code{GENERIC} and using
180 preprocessor directives.
182 @smallexample
183 (simplify
184   (bit_and:c integral_op_p@@0 (bit_ior:c (bit_not @@0) @@1))
185   (bit_and @@1 @@0))
186 @end smallexample
188 Here we introduce flags on match expressions.  There is currently
189 a single flag, @code{c}, which denotes that the expression should
190 be also matched commutated.  Thus the above match expression
191 is really the following four match expressions:
193   (bit_and integral_op_p@@0 (bit_ior (bit_not @@0) @@1))
194   (bit_and (bit_ior (bit_not @@0) @@1) integral_op_p@@0)
195   (bit_and integral_op_p@@0 (bit_ior @@1 (bit_not @@0)))
196   (bit_and (bit_ior @@1 (bit_not @@0)) integral_op_p@@0)
198 Usual canonicalizations you know from GENERIC expressions are
199 applied before matching, so for example constant operands always
200 come second in commutative expressions.
202 More features exist to avoid too much repetition.
204 @smallexample
205 (for op (plus pointer_plus minus bit_ior bit_xor)
206   (simplify
207     (op @@0 integer_zerop)
208     @@0))
209 @end smallexample
211 A @code{for} expression can be used to repeat a pattern for each
212 operator specified, substituting @code{op}.  @code{for} can be
213 nested and a @code{for} can have multiple operators to iterate.
215 @smallexample
216 (for opa (plus minus)
217      opb (minus plus)
218   (for opc (plus minus)
219     (simplify...
220 @end smallexample
222 In this example the pattern will be repeated four times with
223 @code{opa, opb, opc} being @code{plus, minus, plus},
224 @code{plus, minus, minus}, @code{minus, plus, plus},
225 @code{minus, plus, minus}.
227 To avoid repeating operator lists in @code{for} you can name
228 them via
230 @smallexample
231 (define_operator_list pmm plus minus mult)
232 @end smallexample
234 and use them in @code{for} operator lists where they get expanded.
236 @smallexample
237 (for opa (pmm trunc_div)
238  (simplify...
239 @end smallexample
241 So this example iterates over @code{plus}, @code{minus}, @code{mult}
242 and @code{trunc_div}.
244 Using operator lists can also remove the need to explicitely write
245 a @code{for}.  All operator list uses that appear in a @code{simplify}
246 or @code{match} pattern in operator positions will implicitely
247 be added to a new @code{for}.  For example
249 @smallexample
250 (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL)
251 (define_operator_list POW BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL)
252 (simplify
253  (SQRT (POW @@0 @@1))
254  (POW (abs @@0) (mult @@1 @{ built_real (TREE_TYPE (@@1), dconsthalf); @})))
255 @end smallexample
257 is the same as
259 @smallexample
260 (for SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL)
261      POW (BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL)
262  (simplify
263   (SQRT (POW @@0 @@1))
264   (POW (abs @@0) (mult @@1 @{ built_real (TREE_TYPE (@@1), dconsthalf); @}))))
265 @end smallexample
267 Another building block are @code{with} expressions in the
268 result expression which nest the generated code in a new C block
269 followed by its argument:
271 @smallexample
272 (simplify
273  (convert (mult @@0 @@1))
274  (with @{ tree utype = unsigned_type_for (type); @}
275   (convert (mult (convert:utype @@0) (convert:utype @@1)))))
276 @end smallexample
278 This allows code nested in the @code{with} to refer to the declared
279 variables.  In the above case we use the feature to specify the
280 type of a generated expression with the @code{:type} syntax where
281 @code{type} needs to be an identifier that refers to the desired type.
282 Usually the types of the generated result expressions are
283 determined from the context, but sometimes like in the above case
284 it is required that you specify them explicitely.
286 As intermediate conversions are often optional there is a way to
287 avoid the need to repeat patterns both with and without such
288 conversions.  Namely you can mark a conversion as being optional
289 with a @code{?}:
291 @smallexample
292 (simplify
293  (eq (convert@@0 @@1) (convert? @@2))
294  (eq @@1 (convert @@2)))
295 @end smallexample
297 which will match both @code{(eq (convert @@1) (convert @@2))} and
298 @code{(eq (convert @@1) @@2)}.  The optional converts are supposed
299 to be all either present or not, thus
300 @code{(eq (convert? @@1) (convert? @@2))} will result in two
301 patterns only.  If you want to match all four combinations you
302 have access to two additional conditional converts as in
303 @code{(eq (convert1? @@1) (convert2? @@2))}.
305 Predicates available from the GCC middle-end need to be made
306 available explicitely via @code{define_predicates}:
308 @smallexample
309 (define_predicates
310  integer_onep integer_zerop integer_all_onesp)
311 @end smallexample
313 You can also define predicates using the pattern matching language
314 and the @code{match} form:
316 @smallexample
317 (match negate_expr_p
318  INTEGER_CST
319  (if (TYPE_OVERFLOW_WRAPS (type)
320       || may_negate_without_overflow_p (t))))
321 (match negate_expr_p
322  (negate @@0))
323 @end smallexample
325 This shows that for @code{match} expressions there is @code{t}
326 available which captures the outermost expression (something
327 not possible in the @code{simplify} context).  As you can see
328 @code{match} has an identifier as first operand which is how
329 you refer to the predicate in patterns.  Multiple @code{match}
330 for the same identifier add additional cases where the predicate
331 matches.
333 Predicates can also match an expression in which case you need
334 to provide a template specifying the identifier and where to
335 get its operands from:
337 @smallexample
338 (match (logical_inverted_value @@0)
339  (eq @@0 integer_zerop))
340 (match (logical_inverted_value @@0)
341  (bit_not truth_valued_p@@0))
342 @end smallexample
344 You can use the above predicate like
346 @smallexample
347 (simplify
348  (bit_and @@0 (logical_inverted_value @@0))
349  @{ build_zero_cst (type); @})
350 @end smallexample
352 Which will match a bitwise and of an operand with its logical
353 inverted value.