| blob | f97bd6131048937269ac1ac7e09eb595cd2b45b9 |
1 /* Support routines for Value Range Propagation (VRP).
2 Copyright (C) 2005, 2006, 2007 Free Software Foundation, Inc.
3 Contributed by Diego Novillo <dnovillo@redhat.com>.
5 This file is part of GCC.
7 GCC is free software; you can redistribute it and/or modify
8 it under the terms of the GNU General Public License as published by
9 the Free Software Foundation; either version 2, or (at your option)
10 any later version.
12 GCC is distributed in the hope that it will be useful,
13 but WITHOUT ANY WARRANTY; without even the implied warranty of
14 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
15 GNU General Public License for more details.
17 You should have received a copy of the GNU General Public License
18 along with GCC; see the file COPYING. If not, write to
19 the Free Software Foundation, 51 Franklin Street, Fifth Floor,
20 Boston, MA 02110-1301, USA. */
42 /* Set of SSA names found during the dominator traversal of a
43 sub-graph in find_assert_locations. */
46 /* Local functions. */
51 /* Location information for ASSERT_EXPRs. Each instance of this
52 structure describes an ASSERT_EXPR for an SSA name. Since a single
53 SSA name may have more than one assertion associated with it, these
54 locations are kept in a linked list attached to the corresponding
55 SSA name. */
56 struct assert_locus_d
57 {
58 /* Basic block where the assertion would be inserted. */
59 basic_block bb;
61 /* Some assertions need to be inserted on an edge (e.g., assertions
62 generated by COND_EXPRs). In those cases, BB will be NULL. */
63 edge e;
65 /* Pointer to the statement that generated this assertion. */
66 block_stmt_iterator si;
68 /* Predicate code for the ASSERT_EXPR. Must be COMPARISON_CLASS_P. */
71 /* Value being compared against. */
72 tree val;
74 /* Next node in the linked list. */
76 };
80 /* If bit I is present, it means that SSA name N_i has a list of
81 assertions that should be inserted in the IL. */
84 /* Array of locations lists where to insert assertions. ASSERTS_FOR[I]
85 holds a list of ASSERT_LOCUS_T nodes that describe where
86 ASSERT_EXPRs for SSA name N_I should be inserted. */
89 /* Set of blocks visited in find_assert_locations. Used to avoid
90 visiting the same block more than once. */
93 /* Value range array. After propagation, VR_VALUE[I] holds the range
94 of values that SSA name N_I may take. */
98 /* Return whether TYPE should use an overflow infinity distinct from
99 TYPE_{MIN,MAX}_VALUE. We use an overflow infinity value to
100 represent a signed overflow during VRP computations. An infinity
101 is distinct from a half-range, which will go from some number to
102 TYPE_{MIN,MAX}_VALUE. */
106 {
108 }
110 /* Return whether TYPE can support our overflow infinity
111 representation: we use the TREE_OVERFLOW flag, which only exists
112 for constants. If TYPE doesn't support this, we don't optimize
113 cases which would require signed overflow--we drop them to
114 VARYING. */
118 {
119 #ifdef ENABLE_CHECKING
121 #endif
126 }
128 /* VAL is the maximum or minimum value of a type. Return a
129 corresponding overflow infinity. */
133 {
134 #ifdef ENABLE_CHECKING
136 #endif
140 }
142 /* Return a negative overflow infinity for TYPE. */
146 {
147 #ifdef ENABLE_CHECKING
149 #endif
151 }
153 /* Return a positive overflow infinity for TYPE. */
157 {
158 #ifdef ENABLE_CHECKING
160 #endif
162 }
164 /* Return whether VAL is a negative overflow infinity. */
168 {
173 }
175 /* Return whether VAL is a positive overflow infinity. */
179 {
184 }
186 /* Return whether VAL is a positive or negative overflow infinity. */
190 {
196 }
198 /* If VAL is now an overflow infinity, return VAL. Otherwise, return
199 the same value with TREE_OVERFLOW clear. This can be used to avoid
200 confusing a regular value with an overflow value. */
204 {
210 else
211 {
212 #ifdef ENABLE_CHECKING
214 #endif
216 }
217 }
220 /* Return whether VAL is equal to the maximum value of its type. This
221 will be true for a positive overflow infinity. We can't do a
222 simple equality comparison with TYPE_MAX_VALUE because C typedefs
223 and Ada subtypes can produce types whose TYPE_MAX_VALUE is not ==
224 to the integer constant with the same value in the type. */
228 {
234 }
236 /* Return whether VAL is equal to the minimum value of its type. This
237 will be true for a negative overflow infinity. */
241 {
247 }
250 /* Return true if ARG is marked with the nonnull attribute in the
251 current function signature. */
253 static bool
255 {
261 /* The static chain decl is always non null. */
268 /* If "nonnull" wasn't specified, we know nothing about the argument. */
272 /* If "nonnull" applies to all the arguments, then ARG is non-null. */
276 /* Get the position number for ARG in the function signature. */
278 t;
280 {
283 }
287 /* Now see if ARG_NUM is mentioned in the nonnull list. */
289 {
292 }
295 }
298 /* Set value range VR to {T, MIN, MAX, EQUIV}. */
300 static void
303 {
304 #if defined ENABLE_CHECKING
305 /* Check the validity of the range. */
307 {
321 }
328 #endif
334 /* Since updating the equivalence set involves deep copying the
335 bitmaps, only do it if absolutely necessary. */
340 {
343 else
345 }
346 }
349 /* Copy value range FROM into value range TO. */
353 {
355 }
358 /* Set value range VR to VR_VARYING. */
362 {
367 }
369 /* Set value range VR to a single value. This function is only called
370 with values we get from statements, and exists to clear the
371 TREE_OVERFLOW flag so that we don't think we have an overflow
372 infinity when we shouldn't. */
376 {
380 }
382 /* Set value range VR to a non-negative range of type TYPE.
383 OVERFLOW_INFINITY indicates whether to use a overflow infinity
384 rather than TYPE_MAX_VALUE; this should be true if we determine
385 that the range is nonnegative based on the assumption that signed
386 overflow does not occur. */
391 {
392 tree zero;
395 {
398 }
402 (overflow_infinity
406 }
408 /* Set value range VR to a non-NULL range of type TYPE. */
412 {
415 }
418 /* Set value range VR to a NULL range of type TYPE. */
422 {
424 }
427 /* Set value range VR to VR_UNDEFINED. */
431 {
436 }
439 /* Return value range information for VAR.
441 If we have no values ranges recorded (ie, VRP is not running), then
442 return NULL. Otherwise create an empty range if none existed for VAR. */
446 {
448 tree sym;
451 /* If we have no recorded ranges, then return NULL. */
459 /* Create a default value range. */
463 /* Allocate an equivalence set. */
466 /* If VAR is a default definition, the variable can take any value
467 in VAR's type. */
470 {
471 /* Try to use the "nonnull" attribute to create ~[0, 0]
472 anti-ranges for pointers. Note that this is only valid with
473 default definitions of PARM_DECLs. */
478 else
480 }
483 }
485 /* Return true, if VAL1 and VAL2 are equal values for VRP purposes. */
489 {
497 }
499 /* Return true, if the bitmaps B1 and B2 are equal. */
503 {
507 }
509 /* Update the value range and equivalence set for variable VAR to
510 NEW_VR. Return true if NEW_VR is different from VAR's previous
511 value.
513 NOTE: This function assumes that NEW_VR is a temporary value range
514 object created for the sole purpose of updating VAR's range. The
515 storage used by the equivalence set from NEW_VR will be freed by
516 this function. Do not call update_value_range when NEW_VR
517 is the range object associated with another SSA name. */
521 {
525 /* Update the value range, if necessary. */
540 }
543 /* Add VAR and VAR's equivalence set to EQUIV. */
545 static void
547 {
554 }
557 /* Return true if VR is ~[0, 0]. */
561 {
565 }
568 /* Return true if VR is [0, 0]. */
572 {
576 }
579 /* Return true if value range VR involves at least one symbol. */
583 {
586 }
588 /* Return true if value range VR uses a overflow infinity. */
592 {
596 }
598 /* Return false if we can not make a valid comparison based on VR;
599 this will be the case if it uses an overflow infinity and overflow
600 is not undefined (i.e., -fno-strict-overflow is in effect).
601 Otherwise return true, and set *STRICT_OVERFLOW_P to true if VR
602 uses an overflow infinity. */
604 static bool
606 {
609 {
613 }
615 {
619 }
621 }
624 /* Like tree_expr_nonnegative_warnv_p, but this function uses value
625 ranges obtained so far. */
627 static bool
629 {
631 }
633 /* Like tree_expr_nonzero_warnv_p, but this function uses value ranges
634 obtained so far. */
636 static bool
638 {
642 /* If we have an expression of the form &X->a, then the expression
643 is nonnull if X is nonnull. */
645 {
651 {
655 }
656 }
659 }
661 /* Returns true if EXPR is a valid value (as expected by compare_values) --
662 a gimple invariant, or SSA_NAME +- CST. */
664 static bool
666 {
676 }
678 /* Compare two values VAL1 and VAL2. Return
680 -2 if VAL1 and VAL2 cannot be compared at compile-time,
681 -1 if VAL1 < VAL2,
682 0 if VAL1 == VAL2,
683 +1 if VAL1 > VAL2, and
684 +2 if VAL1 != VAL2
686 This is similar to tree_int_cst_compare but supports pointer values
687 and values that cannot be compared at compile time.
689 If STRICT_OVERFLOW_P is not NULL, then set *STRICT_OVERFLOW_P to
690 true if the return value is only valid if we assume that signed
691 overflow is undefined. */
693 static int
695 {
699 /* Below we rely on the fact that VAL1 and VAL2 are both pointers or
700 both integers. */
710 {
714 /* If VAL1 and VAL2 are of the form 'NAME [+-] CST' or 'NAME',
715 return -1 or +1 accordingly. If VAL1 and VAL2 don't use the
716 same name, return -2. */
718 {
722 }
723 else
724 {
729 {
736 }
737 }
740 {
744 }
745 else
746 {
751 {
758 }
759 }
761 /* Both values must use the same name. */
767 /* NAME == NAME */
770 /* If overflow is defined we cannot simplify more. */
780 {
782 /* NAME < NAME + CST */
785 /* NAME > NAME - CST */
787 }
789 {
791 /* NAME + CST > NAME */
794 /* NAME + CST1 > NAME + CST2, if CST1 > CST2 */
797 /* NAME + CST1 > NAME - CST2 */
799 }
801 {
803 /* NAME - CST < NAME */
806 /* NAME - CST1 < NAME + CST2 */
809 /* NAME - CST1 > NAME - CST2, if CST1 < CST2. Notice that
810 C1 and C2 are swapped in the call to compare_values. */
812 }
815 }
817 /* We cannot compare non-constants. */
822 {
823 /* We cannot compare overflowed values, except for overflow
824 infinities. */
826 {
838 }
841 }
842 else
843 {
844 tree t;
846 /* First see if VAL1 and VAL2 are not the same. */
850 /* If VAL1 is a lower address than VAL2, return -1. */
855 /* If VAL1 is a higher address than VAL2, return +1. */
860 /* If VAL1 is different than VAL2, return +2. */
866 }
867 }
869 /* Compare values like compare_values_warnv, but treat comparisons of
870 nonconstants which rely on undefined overflow as incomparable. */
872 static int
874 {
884 }
887 /* Return 1 if VAL is inside value range VR (VR->MIN <= VAL <= VR->MAX),
888 0 if VAL is not inside VR,
889 -2 if we cannot tell either way.
891 FIXME, the current semantics of this functions are a bit quirky
892 when taken in the context of VRP. In here we do not care
893 about VR's type. If VR is the anti-range ~[3, 5] the call
894 value_inside_range (4, VR) will return 1.
896 This is counter-intuitive in a strict sense, but the callers
897 currently expect this. They are calling the function
898 merely to determine whether VR->MIN <= VAL <= VR->MAX. The
899 callers are applying the VR_RANGE/VR_ANTI_RANGE semantics
900 themselves.
902 This also applies to value_ranges_intersect_p and
903 range_includes_zero_p. The semantics of VR_RANGE and
904 VR_ANTI_RANGE should be encoded here, but that also means
905 adapting the users of these functions to the new semantics. */
909 {
916 {
919 }
929 }
932 /* Return true if value ranges VR0 and VR1 have a non-empty
933 intersection. */
937 {
942 }
945 /* Return true if VR includes the value zero, false otherwise. FIXME,
946 currently this will return false for an anti-range like ~[-4, 3].
947 This will be wrong when the semantics of value_inside_range are
948 modified (currently the users of this function expect these
949 semantics). */
953 {
954 tree zero;
962 }
964 /* Return true if T, an SSA_NAME, is known to be nonnegative. Return
965 false otherwise or if no value range information is available. */
967 bool
969 {
975 /* Testing for VR_ANTI_RANGE is not useful here as any anti-range
976 which would return a useful value should be encoded as a VR_RANGE. */
978 {
982 }
984 }
986 /* Return true if T, an SSA_NAME, is known to be nonzero. Return
987 false otherwise or if no value range information is available. */
989 bool
991 {
997 /* A VR_RANGE which does not include zero is a nonzero value. */
1001 /* A VR_ANTI_RANGE which does include zero is a nonzero value. */
1006 }
1009 /* Extract value range information from an ASSERT_EXPR EXPR and store
1010 it in *VR_P. */
1012 static void
1014 {
1024 /* Find VAR in the ASSERT_EXPR conditional. */
1026 {
1027 /* If the predicate is of the form VAR COMP LIMIT, then we just
1028 take LIMIT from the RHS and use the same comparison code. */
1031 }
1032 else
1033 {
1034 /* If the predicate is of the form LIMIT COMP VAR, then we need
1035 to flip around the comparison code to create the proper range
1036 for VAR. */
1039 }
1046 /* For pointer arithmetic, we only keep track of pointer equality
1047 and inequality. */
1049 {
1052 }
1054 /* If LIMIT is another SSA name and LIMIT has a range of its own,
1055 try to use LIMIT's range to avoid creating symbolic ranges
1056 unnecessarily. */
1059 /* LIMIT's range is only interesting if it has any useful information. */
1066 /* Initially, the new range has the same set of equivalences of
1067 VAR's range. This will be revised before returning the final
1068 value. Since assertions may be chained via mutually exclusive
1069 predicates, we will need to trim the set of equivalences before
1070 we are done. */
1075 /* Extract a new range based on the asserted comparison for VAR and
1076 LIMIT's value range. Notice that if LIMIT has an anti-range, we
1077 will only use it for equality comparisons (EQ_EXPR). For any
1078 other kind of assertion, we cannot derive a range from LIMIT's
1079 anti-range that can be used to describe the new range. For
1080 instance, ASSERT_EXPR <x_2, x_2 <= b_4>. If b_4 is ~[2, 10],
1081 then b_4 takes on the ranges [-INF, 1] and [11, +INF]. There is
1082 no single range for x_2 that could describe LE_EXPR, so we might
1083 as well build the range [b_4, +INF] for it. */
1085 {
1089 {
1093 }
1094 else
1095 {
1099 }
1103 /* When asserting the equality VAR == LIMIT and LIMIT is another
1104 SSA name, the new range will also inherit the equivalence set
1105 from LIMIT. */
1108 }
1110 {
1111 /* As described above, when LIMIT's range is an anti-range and
1112 this assertion is an inequality (NE_EXPR), then we cannot
1113 derive anything from the anti-range. For instance, if
1114 LIMIT's range was ~[0, 0], the assertion 'VAR != LIMIT' does
1115 not imply that VAR's range is [0, 0]. So, in the case of
1116 anti-ranges, we just assert the inequality using LIMIT and
1117 not its anti-range.
1119 If LIMIT_VR is a range, we can only use it to build a new
1120 anti-range if LIMIT_VR is a single-valued range. For
1121 instance, if LIMIT_VR is [0, 1], the predicate
1122 VAR != [0, 1] does not mean that VAR's range is ~[0, 1].
1123 Rather, it means that for value 0 VAR should be ~[0, 0]
1124 and for value 1, VAR should be ~[1, 1]. We cannot
1125 represent these ranges.
1127 The only situation in which we can build a valid
1128 anti-range is when LIMIT_VR is a single-valued range
1129 (i.e., LIMIT_VR->MIN == LIMIT_VR->MAX). In that case,
1130 build the anti-range ~[LIMIT_VR->MIN, LIMIT_VR->MAX]. */
1134 {
1137 }
1138 else
1139 {
1140 /* In any other case, we cannot use LIMIT's range to build a
1141 valid anti-range. */
1143 }
1145 /* If MIN and MAX cover the whole range for their type, then
1146 just use the original LIMIT. */
1153 }
1155 {
1160 else
1161 {
1162 /* If LIMIT_VR is of the form [N1, N2], we need to build the
1163 range [MIN, N2] for LE_EXPR and [MIN, N2 - 1] for
1164 LT_EXPR. */
1166 }
1168 /* If the maximum value forces us to be out of bounds, simply punt.
1169 It would be pointless to try and do anything more since this
1170 all should be optimized away above us. */
1175 else
1176 {
1177 /* For LT_EXPR, we create the range [MIN, MAX - 1]. */
1179 {
1184 }
1187 }
1188 }
1190 {
1195 else
1196 {
1197 /* If LIMIT_VR is of the form [N1, N2], we need to build the
1198 range [N1, MAX] for GE_EXPR and [N1 + 1, MAX] for
1199 GT_EXPR. */
1201 }
1203 /* If the minimum value forces us to be out of bounds, simply punt.
1204 It would be pointless to try and do anything more since this
1205 all should be optimized away above us. */
1210 else
1211 {
1212 /* For GT_EXPR, we create the range [MIN + 1, MAX]. */
1214 {
1219 }
1222 }
1223 }
1224 else
1227 /* If VAR already had a known range, it may happen that the new
1228 range we have computed and VAR's range are not compatible. For
1229 instance,
1231 if (p_5 == NULL)
1232 p_6 = ASSERT_EXPR <p_5, p_5 == NULL>;
1233 x_7 = p_6->fld;
1234 p_8 = ASSERT_EXPR <p_6, p_6 != NULL>;
1236 While the above comes from a faulty program, it will cause an ICE
1237 later because p_8 and p_6 will have incompatible ranges and at
1238 the same time will be considered equivalent. A similar situation
1239 would arise from
1241 if (i_5 > 10)
1242 i_6 = ASSERT_EXPR <i_5, i_5 > 10>;
1243 if (i_5 < 5)
1244 i_7 = ASSERT_EXPR <i_6, i_6 < 5>;
1246 Again i_6 and i_7 will have incompatible ranges. It would be
1247 pointless to try and do anything with i_7's range because
1248 anything dominated by 'if (i_5 < 5)' will be optimized away.
1249 Note, due to the wa in which simulation proceeds, the statement
1250 i_7 = ASSERT_EXPR <...> we would never be visited because the
1251 conditional 'if (i_5 < 5)' always evaluates to false. However,
1252 this extra check does not hurt and may protect against future
1253 changes to VRP that may get into a situation similar to the
1254 NULL pointer dereference example.
1256 Note that these compatibility tests are only needed when dealing
1257 with ranges or a mix of range and anti-range. If VAR_VR and VR_P
1258 are both anti-ranges, they will always be compatible, because two
1259 anti-ranges will always have a non-empty intersection. */
1263 /* We may need to make adjustments when VR_P and VAR_VR are numeric
1264 ranges or anti-ranges. */
1274 {
1275 /* If the two ranges have a non-empty intersection, we can
1276 refine the resulting range. Since the assert expression
1277 creates an equivalency and at the same time it asserts a
1278 predicate, we can take the intersection of the two ranges to
1279 get better precision. */
1281 {
1282 /* Use the larger of the two minimums. */
1285 else
1288 /* Use the smaller of the two maximums. */
1291 else
1295 }
1296 else
1297 {
1298 /* The two ranges do not intersect, set the new range to
1299 VARYING, because we will not be able to do anything
1300 meaningful with it. */
1302 }
1303 }
1306 {
1307 /* A range and an anti-range will cancel each other only if
1308 their ends are the same. For instance, in the example above,
1309 p_8's range ~[0, 0] and p_6's range [0, 0] are incompatible,
1310 so VR_P should be set to VR_VARYING. */
1314 else
1315 {
1318 /* We want to compute the logical AND of the two ranges;
1319 there are three cases to consider.
1322 1. The VR_ANTI_RANGE range is completely within the
1323 VR_RANGE and the endpoints of the ranges are
1324 different. In that case the resulting range
1325 should be whichever range is more precise.
1326 Typically that will be the VR_RANGE.
1328 2. The VR_ANTI_RANGE is completely disjoint from
1329 the VR_RANGE. In this case the resulting range
1330 should be the VR_RANGE.
1332 3. There is some overlap between the VR_ANTI_RANGE
1333 and the VR_RANGE.
1335 3a. If the high limit of the VR_ANTI_RANGE resides
1336 within the VR_RANGE, then the result is a new
1337 VR_RANGE starting at the high limit of the
1338 the VR_ANTI_RANGE + 1 and extending to the
1339 high limit of the original VR_RANGE.
1341 3b. If the low limit of the VR_ANTI_RANGE resides
1342 within the VR_RANGE, then the result is a new
1343 VR_RANGE starting at the low limit of the original
1344 VR_RANGE and extending to the low limit of the
1345 VR_ANTI_RANGE - 1. */
1347 {
1352 }
1353 else
1354 {
1359 }
1362 /* Case 1, VR_ANTI_RANGE completely within VR_RANGE,
1363 not including any endpoints. */
1366 {
1369 }
1370 /* Case 2, VR_ANTI_RANGE completely disjoint from
1371 VR_RANGE. */
1374 {
1377 }
1378 /* Case 3a, the anti-range extends into the low
1379 part of the real range. Thus creating a new
1380 low for the real range. */
1384 {
1388 {
1390 {
1393 }
1395 }
1396 else
1398 anti_max,
1402 }
1403 /* Case 3b, the anti-range extends into the high
1404 part of the real range. Thus creating a new
1405 higher for the real range. */
1409 {
1413 {
1415 {
1418 }
1420 }
1421 else
1423 anti_min,
1427 }
1428 }
1429 }
1430 }
1433 /* Extract range information from SSA name VAR and store it in VR. If
1434 VAR has an interesting range, use it. Otherwise, create the
1435 range [VAR, VAR] and return it. This is useful in situations where
1436 we may have conditionals testing values of VARYING names. For
1437 instance,
1439 x_3 = y_5;
1440 if (x_3 > y_5)
1441 ...
1443 Even if y_5 is deemed VARYING, we can determine that x_3 > y_5 is
1444 always false. */
1446 static void
1448 {
1453 else
1457 }
1460 /* Wrapper around int_const_binop. If the operation overflows and we
1461 are not using wrapping arithmetic, then adjust the result to be
1462 -INF or +INF depending on CODE, VAL1 and VAL2. This can return
1463 NULL_TREE if we need to use an overflow infinity representation but
1464 the type does not support it. */
1466 static tree
1468 {
1469 tree res;
1473 /* If we are not using wrapping arithmetic, operate symbolically
1474 on -INF and +INF. */
1476 {
1480 /* Ensure that res = val1 [+*] val2 >= val1
1481 or that res = val1 - val2 <= val1. */
1486 {
1488 }
1489 /* Checking for multiplication overflow is done by dividing the
1490 output of the multiplication by the first input of the
1491 multiplication. If the result of that division operation is
1492 not equal to the second input of the multiplication, then the
1493 multiplication overflowed. */
1495 {
1497 res,
1503 }
1506 {
1509 }
1511 }
1517 {
1518 /* If the operation overflowed but neither VAL1 nor VAL2 are
1519 overflown, return -INF or +INF depending on the operation
1520 and the combination of signs of the operands. */
1528 /* We have to punt on adding infinities of different signs,
1529 since we can't tell what the sign of the result should be.
1530 Likewise for subtracting infinities of the same sign. */
1537 /* Don't try to handle division or shifting of infinities. */
1548 /* Notice that we only need to handle the restricted set of
1549 operations handled by extract_range_from_binary_expr.
1550 Among them, only multiplication, addition and subtraction
1551 can yield overflow without overflown operands because we
1552 are working with integral types only... except in the
1553 case VAL1 = -INF and VAL2 = -1 which overflows to +INF
1554 for division too. */
1556 /* For multiplication, the sign of the overflow is given
1557 by the comparison of the signs of the operands. */
1559 /* For addition, the operands must be of the same sign
1560 to yield an overflow. Its sign is therefore that
1561 of one of the operands, for example the first. For
1562 infinite operands X + -INF is negative, not positive. */
1567 /* For subtraction, non-infinite operands must be of
1568 different signs to yield an overflow. Its sign is
1569 therefore that of the first operand or the opposite of
1570 that of the second operand. A first operand of 0 counts
1571 as positive here, for the corner case 0 - (-INF), which
1572 overflows, but must yield +INF. For infinite operands 0
1573 - INF is negative, not positive. */
1578 /* For division, the only case is -INF / -1 = +INF. */
1587 else
1591 }
1594 }
1597 /* Extract range information from a binary expression EXPR based on
1598 the ranges of each of its operands and the expression code. */
1600 static void
1602 {
1610 /* Not all binary expressions can be applied to ranges in a
1611 meaningful way. Handle only arithmetic operations. */
1627 {
1630 }
1632 /* Get value ranges for each operand. For constant operands, create
1633 a new value range with the operand to simplify processing. */
1639 else
1647 else
1650 /* If either range is UNDEFINED, so is the result. */
1652 {
1655 }
1657 /* The type of the resulting value range defaults to VR0.TYPE. */
1660 /* Refuse to operate on VARYING ranges, ranges of different kinds
1661 and symbolic ranges. As an exception, we allow BIT_AND_EXPR
1662 because we may be able to derive a useful range even if one of
1663 the operands is VR_VARYING or symbolic range. TODO, we may be
1664 able to derive anti-ranges in some cases. */
1673 {
1676 }
1678 /* Now evaluate the expression to determine the new range. */
1682 {
1683 /* For pointer types, we are really only interested in asserting
1684 whether the expression evaluates to non-NULL. FIXME, we used
1685 to gcc_assert (code == PLUS_EXPR || code == MINUS_EXPR), but
1686 ivopts is generating expressions with pointer multiplication
1687 in them. */
1689 {
1694 else
1696 }
1697 else
1698 {
1699 /* Subtracting from a pointer, may yield 0, so just drop the
1700 resulting range to varying. */
1702 }
1705 }
1707 /* For integer ranges, apply the operation to each end of the
1708 range and see what we end up with. */
1713 {
1714 /* If one of the operands is zero, we know that the whole
1715 expression evaluates zero. */
1723 {
1726 }
1727 /* If one of the operands is one, we know that the whole
1728 expression evaluates one. */
1736 {
1739 }
1747 {
1748 /* Boolean expressions cannot be folded with int_const_binop. */
1751 }
1752 else
1753 {
1756 }
1757 }
1761 {
1762 /* If we have a PLUS_EXPR with two VR_ANTI_RANGEs, drop to
1763 VR_VARYING. It would take more effort to compute a precise
1764 range for such a case. For example, if we have op0 == 1 and
1765 op1 == -1 with their ranges both being ~[0,0], we would have
1766 op0 + op1 == 0, so we cannot claim that the sum is in ~[0,0].
1767 Note that we are guaranteed to have vr0.type == vr1.type at
1768 this point. */
1770 {
1773 }
1775 /* For operations that make the resulting range directly
1776 proportional to the original ranges, apply the operation to
1777 the same end of each range. */
1780 }
1787 {
1792 /* If we have an unsigned MULT_EXPR with two VR_ANTI_RANGEs,
1793 drop to VR_VARYING. It would take more effort to compute a
1794 precise range for such a case. For example, if we have
1795 op0 == 65536 and op1 == 65536 with their ranges both being
1796 ~[0,0] on a 32-bit machine, we would have op0 * op1 == 0, so
1797 we cannot claim that the product is in ~[0,0]. Note that we
1798 are guaranteed to have vr0.type == vr1.type at this
1799 point. */
1803 {
1806 }
1808 /* Multiplications and divisions are a bit tricky to handle,
1809 depending on the mix of signs we have in the two ranges, we
1810 need to operate on different values to get the minimum and
1811 maximum values for the new range. One approach is to figure
1812 out all the variations of range combinations and do the
1813 operations.
1815 However, this involves several calls to compare_values and it
1816 is pretty convoluted. It's simpler to do the 4 operations
1817 (MIN0 OP MIN1, MIN0 OP MAX1, MAX0 OP MIN1 and MAX0 OP MAX0 OP
1818 MAX1) and then figure the smallest and largest values to form
1819 the new range. */
1821 /* Divisions by zero result in a VARYING value. */
1824 {
1827 }
1829 /* Compute the 4 cross operations. */
1837 else
1838 {
1842 }
1846 else
1847 {
1851 }
1855 else
1856 {
1860 }
1863 {
1866 }
1868 /* Set MIN to the minimum of VAL[i] and MAX to the maximum
1869 of VAL[i]. */
1873 {
1881 {
1885 {
1886 /* If we found an overflowed value, set MIN and MAX
1887 to it so that we set the resulting range to
1888 VARYING. */
1891 }
1898 }
1899 }
1900 }
1902 {
1903 /* If we have a MINUS_EXPR with two VR_ANTI_RANGEs, drop to
1904 VR_VARYING. It would take more effort to compute a precise
1905 range for such a case. For example, if we have op0 == 1 and
1906 op1 == 1 with their ranges both being ~[0,0], we would have
1907 op0 - op1 == 0, so we cannot claim that the difference is in
1908 ~[0,0]. Note that we are guaranteed to have
1909 vr0.type == vr1.type at this point. */
1911 {
1914 }
1916 /* For MINUS_EXPR, apply the operation to the opposite ends of
1917 each range. */
1920 }
1922 {
1928 {
1931 }
1937 {
1941 }
1942 else
1943 {
1946 }
1947 }
1948 else
1951 /* If either MIN or MAX overflowed, then set the resulting range to
1952 VARYING. But we do accept an overflow infinity
1953 representation. */
1960 {
1963 }
1965 /* We punt if:
1966 1) [-INF, +INF]
1967 2) [-INF, +-INF(OVF)]
1968 3) [+-INF(OVF), +INF]
1969 4) [+-INF(OVF), +-INF(OVF)]
1970 We learn nothing when we have INF and INF(OVF) on both sides.
1971 Note that we do accept [-INF, -INF] and [+INF, +INF] without
1972 overflow. */
1975 {
1978 }
1982 {
1983 /* If the new range has its limits swapped around (MIN > MAX),
1984 then the operation caused one of them to wrap around, mark
1985 the new range VARYING. */
1987 }
1988 else
1990 }
1993 /* Extract range information from a unary expression EXPR based on
1994 the range of its operand and the expression code. */
1996 static void
1998 {
2004 /* Refuse to operate on certain unary expressions for which we
2005 cannot easily determine a resulting range. */
2014 {
2017 }
2019 /* Get value ranges for the operand. For constant operands, create
2020 a new value range with the operand to simplify processing. */
2026 else
2029 /* If VR0 is UNDEFINED, so is the result. */
2031 {
2034 }
2036 /* Refuse to operate on symbolic ranges, or if neither operand is
2037 a pointer or integral type. */
2042 {
2045 }
2047 /* If the expression involves pointers, we are only interested in
2048 determining if it evaluates to NULL [0, 0] or non-NULL (~[0, 0]). */
2050 {
2060 else
2064 }
2066 /* Handle unary expressions on integer ranges. */
2068 {
2072 /* If VR0 represents a simple range, then try to convert
2073 the min and max values for the range to the same type
2074 as OUTER_TYPE. If the results compare equal to VR0's
2075 min and max values and the new min is still less than
2076 or equal to the new max, then we can safely use the newly
2077 computed range for EXPR. This allows us to compute
2078 accurate ranges through many casts. */
2083 {
2086 /* Convert the input operand min/max to OUTER_TYPE. If
2087 the input has no range information, then use the min/max
2088 for the input's type. */
2090 {
2093 }
2094 else
2095 {
2098 }
2103 /* Verify the new min/max values are gimple values and
2104 that they compare equal to the original input's
2105 min/max values. */
2114 {
2117 }
2118 }
2120 /* When converting types of different sizes, set the result to
2121 VARYING. Things like sign extensions and precision loss may
2122 change the range. For instance, if x_3 is of type 'long long
2123 int' and 'y_5 = (unsigned short) x_3', if x_3 is ~[0, 0], it
2124 is impossible to know at compile time whether y_5 will be
2125 ~[0, 0]. */
2128 {
2131 }
2132 }
2134 /* Conversion of a VR_VARYING value to a wider type can result
2135 in a usable range. So wait until after we've handled conversions
2136 before dropping the result to VR_VARYING if we had a source
2137 operand that is VR_VARYING. */
2139 {
2142 }
2144 /* Apply the operation to each end of the range and see what we end
2145 up with. */
2148 {
2149 /* NEGATE_EXPR flips the range around. We need to treat
2150 TYPE_MIN_VALUE specially. */
2158 {
2163 else
2164 {
2167 }
2168 }
2169 else
2179 {
2182 else
2183 {
2186 }
2187 }
2188 else
2190 }
2193 {
2195 {
2198 }
2199 else
2200 {
2203 else
2206 }
2207 }
2210 {
2211 /* -TYPE_MIN_VALUE = TYPE_MIN_VALUE with flag_wrapv so we can't get a
2212 useful range. */
2219 {
2222 }
2224 /* ABS_EXPR may flip the range around, if the original range
2225 included negative values. */
2234 else
2235 {
2238 }
2248 else
2249 {
2252 }
2256 /* If a VR_ANTI_RANGEs contains zero, then we have
2257 ~[-INF, min(MIN, MAX)]. */
2259 {
2261 {
2262 /* Take the lower of the two values. */
2266 /* Create ~[-INF, min (abs(MIN), abs(MAX))]
2267 or ~[-INF + 1, min (abs(MIN), abs(MAX))] when
2268 flag_wrapv is set and the original anti-range doesn't include
2269 TYPE_MIN_VALUE, remember -TYPE_MIN_VALUE = TYPE_MIN_VALUE. */
2271 {
2278 }
2279 else
2280 {
2283 else
2285 }
2286 }
2287 else
2288 {
2289 /* All else has failed, so create the range [0, INF], even for
2290 flag_wrapv since TYPE_MIN_VALUE is in the original
2291 anti-range. */
2295 {
2298 else
2299 {
2302 }
2303 }
2304 else
2306 }
2307 }
2309 /* If the range contains zero then we know that the minimum value in the
2310 range will be zero. */
2312 {
2316 }
2317 else
2318 {
2319 /* If the range was reversed, swap MIN and MAX. */
2321 {
2325 }
2326 }
2327 }
2328 else
2329 {
2330 /* Otherwise, operate on each end of the range. */
2335 {
2338 /* If both sides have overflowed, we don't know
2339 anything. */
2344 {
2347 }
2352 {
2357 else
2358 {
2361 }
2362 }
2367 {
2372 else
2373 {
2376 }
2377 }
2378 }
2379 }
2383 {
2384 /* If the new range has its limits swapped around (MIN > MAX),
2385 then the operation caused one of them to wrap around, mark
2386 the new range VARYING. */
2388 }
2389 else
2391 }
2394 /* Extract range information from a comparison expression EXPR based
2395 on the range of its operand and the expression code. */
2397 static void
2399 {
2403 /* A disadvantage of using a special infinity as an overflow
2404 representation is that we lose the ability to record overflow
2405 when we don't have an infinity. So we have to ignore a result
2406 which relies on overflow. */
2409 {
2410 /* Since this expression was found on the RHS of an assignment,
2411 its type may be different from _Bool. Convert VAL to EXPR's
2412 type. */
2416 else
2418 }
2419 else
2421 }
2424 /* Try to compute a useful range out of expression EXPR and store it
2425 in *VR. */
2427 static void
2429 {
2449 else
2452 /* If we got a varying range from the tests above, try a final
2453 time to derive a nonnegative or nonzero range. This time
2454 relying primarily on generic routines in fold in conjunction
2455 with range data. */
2457 {
2467 }
2468 }
2470 /* Given a range VR, a LOOP and a variable VAR, determine whether it
2471 would be profitable to adjust VR using scalar evolution information
2472 for VAR. If so, update VR with the new limits. */
2474 static void
2476 tree var)
2477 {
2481 /* TODO. Don't adjust anti-ranges. An anti-range may provide
2482 better opportunities than a regular range, but I'm not sure. */
2493 /* If STEP is symbolic, we can't know whether INIT will be the
2494 minimum or maximum value in the range. Also, unless INIT is
2495 a simple expression, compare_values and possibly other functions
2496 in tree-vrp won't be able to handle it. */
2504 or decreases, ... */
2505 dir == EV_DIR_UNKNOWN
2506 /* ... or if it may wrap. */
2514 /* If we see a pointer type starting at a constant, then we have an
2515 unusual ivopt. It may legitimately wrap. */
2519 /* We use TYPE_MIN_VALUE and TYPE_MAX_VALUE here instead of
2520 negative_overflow_infinity and positive_overflow_infinity,
2521 because we have concluded that the loop probably does not
2522 wrap. */
2526 else
2530 else
2534 {
2538 /* For VARYING or UNDEFINED ranges, just about anything we get
2539 from scalar evolutions should be better. */
2543 else
2546 /* If we would create an invalid range, then just assume we
2547 know absolutely nothing. This may be over-conservative,
2548 but it's clearly safe, and should happen only in unreachable
2549 parts of code, or for invalid programs. */
2554 }
2556 {
2561 {
2562 /* INIT is the maximum value. If INIT is lower than VR->MAX
2563 but no smaller than VR->MIN, set VR->MAX to INIT. */
2565 {
2568 /* If we just created an invalid range with the minimum
2569 greater than the maximum, we fail conservatively.
2570 This should happen only in unreachable
2571 parts of code, or for invalid programs. */
2574 }
2576 /* According to the loop information, the variable does not
2577 overflow. If we think it does, probably because of an
2578 overflow due to arithmetic on a different INF value,
2579 reset now. */
2582 }
2583 else
2584 {
2585 /* If INIT is bigger than VR->MIN, set VR->MIN to INIT. */
2587 {
2590 /* Again, avoid creating invalid range by failing. */
2593 }
2597 }
2600 }
2601 }
2603 /* Return true if VAR may overflow at STMT. This checks any available
2604 loop information to see if we can determine that VAR does not
2605 overflow. */
2607 static bool
2609 {
2632 /* If we get here, we know something useful about VAR based on the
2633 loop information. If it wraps, it may overflow. */
2641 {
2644 }
2647 }
2650 /* Given two numeric value ranges VR0, VR1 and a comparison code COMP:
2652 - Return BOOLEAN_TRUE_NODE if VR0 COMP VR1 always returns true for
2653 all the values in the ranges.
2655 - Return BOOLEAN_FALSE_NODE if the comparison always returns false.
2657 - Return NULL_TREE if it is not always possible to determine the
2658 value of the comparison.
2660 Also set *STRICT_OVERFLOW_P to indicate whether a range with an
2661 overflow infinity was used in the test. */
2664 static tree
2667 {
2668 /* VARYING or UNDEFINED ranges cannot be compared. */
2675 /* Anti-ranges need to be handled separately. */
2677 {
2678 /* If both are anti-ranges, then we cannot compute any
2679 comparison. */
2683 /* These comparisons are never statically computable. */
2690 /* Equality can be computed only between a range and an
2691 anti-range. ~[VAL1, VAL2] == [VAL1, VAL2] is always false. */
2693 {
2694 /* To simplify processing, make VR0 the anti-range. */
2698 }
2707 }
2713 /* Simplify processing. If COMP is GT_EXPR or GE_EXPR, switch the
2714 operands around and change the comparison code. */
2716 {
2722 }
2725 {
2726 /* Equality may only be computed if both ranges represent
2727 exactly one value. */
2730 {
2732 strict_overflow_p);
2734 strict_overflow_p);
2739 }
2740 /* If [V0_MIN, V1_MAX] < [V1_MIN, V1_MAX] then V0 != V1. */
2748 }
2750 {
2753 /* If VR0 is completely to the left or completely to the right
2754 of VR1, they are always different. Notice that we need to
2755 make sure that both comparisons yield similar results to
2756 avoid comparing values that cannot be compared at
2757 compile-time. */
2763 /* If VR0 and VR1 represent a single value and are identical,
2764 return false. */
2775 /* Otherwise, they may or may not be different. */
2776 else
2778 }
2780 {
2783 /* If VR0 is to the left of VR1, return true. */
2787 {
2792 }
2794 /* If VR0 is to the right of VR1, return false. */
2798 {
2803 }
2805 /* Otherwise, we don't know. */
2807 }
2810 }
2813 /* Given a value range VR, a value VAL and a comparison code COMP, return
2814 BOOLEAN_TRUE_NODE if VR COMP VAL always returns true for all the
2815 values in VR. Return BOOLEAN_FALSE_NODE if the comparison
2816 always returns false. Return NULL_TREE if it is not always
2817 possible to determine the value of the comparison. Also set
2818 *STRICT_OVERFLOW_P to indicate whether a range with an overflow
2819 infinity was used in the test. */
2821 static tree
2824 {
2828 /* Anti-ranges need to be handled separately. */
2830 {
2831 /* For anti-ranges, the only predicates that we can compute at
2832 compile time are equality and inequality. */
2839 /* ~[VAL_1, VAL_2] OP VAL is known if VAL_1 <= VAL <= VAL_2. */
2844 }
2850 {
2851 /* EQ_EXPR may only be computed if VR represents exactly
2852 one value. */
2854 {
2860 }
2866 }
2868 {
2869 /* If VAL is not inside VR, then they are always different. */
2874 /* If VR represents exactly one value equal to VAL, then return
2875 false. */
2880 /* Otherwise, they may or may not be different. */
2882 }
2884 {
2887 /* If VR is to the left of VAL, return true. */
2891 {
2895 }
2897 /* If VR is to the right of VAL, return false. */
2901 {
2905 }
2907 /* Otherwise, we don't know. */
2909 }
2911 {
2914 /* If VR is to the right of VAL, return true. */
2918 {
2922 }
2924 /* If VR is to the left of VAL, return false. */
2928 {
2932 }
2934 /* Otherwise, we don't know. */
2936 }
2939 }
2942 /* Debugging dumps. */
2952 /* Dump value range VR to FILE. */
2954 void
2956 {
2962 {
2973 else
2983 else
2989 {
2990 bitmap_iterator bi;
2996 {
2999 c++;
3000 }
3003 }
3004 }
3007 else
3009 }
3012 /* Dump value range VR to stderr. */
3014 void
3016 {
3019 }
3022 /* Dump value ranges of all SSA_NAMEs to FILE. */
3024 void
3026 {
3030 {
3032 {
3037 }
3038 }
3041 }
3044 /* Dump all value ranges to stderr. */
3046 void
3048 {
3050 }
3053 /* Given a COND_EXPR COND of the form 'V OP W', and an SSA name V,
3054 create a new SSA name N and return the assertion assignment
3055 'V = ASSERT_EXPR <V, V OP W>'. */
3057 static tree
3059 {
3066 {
3069 }
3071 {
3072 /* Given !V, build the assignment N = false. */
3076 }
3078 {
3079 /* Given V, build the assignment N = true. */
3082 }
3083 else
3088 /* The new ASSERT_EXPR, creates a new SSA name that replaces the
3089 operand of the ASSERT_EXPR. Register the new name and the old one
3090 in the replacement table so that we can fix the SSA web after
3091 adding all the ASSERT_EXPRs. */
3095 }
3098 /* Return false if EXPR is a predicate expression involving floating
3099 point values. */
3103 {
3106 }
3109 /* If the range of values taken by OP can be inferred after STMT executes,
3110 return the comparison code (COMP_CODE_P) and value (VAL_P) that
3111 describes the inferred range. Return true if a range could be
3112 inferred. */
3114 static bool
3116 {
3120 /* Do not attempt to infer anything in names that flow through
3121 abnormal edges. */
3125 /* Similarly, don't infer anything from statements that may throw
3126 exceptions. */
3130 /* If STMT is the last statement of a basic block with no
3131 successors, there is no point inferring anything about any of its
3132 operands. We would not be able to find a proper insertion point
3133 for the assertion, anyway. */
3137 /* We can only assume that a pointer dereference will yield
3138 non-NULL if -fdelete-null-pointer-checks is enabled. */
3140 {
3146 {
3150 }
3151 }
3154 }
3162 /* Dump all the registered assertions for NAME to FILE. */
3164 void
3166 {
3167 assert_locus_t loc;
3175 {
3180 {
3184 }
3191 }
3194 }
3197 /* Dump all the registered assertions for NAME to stderr. */
3199 void
3201 {
3203 }
3206 /* Dump all the registered assertions for all the names to FILE. */
3208 void
3210 {
3212 bitmap_iterator bi;
3218 }
3221 /* Dump all the registered assertions for all the names to stderr. */
3223 void
3225 {
3227 }
3230 /* If NAME doesn't have an ASSERT_EXPR registered for asserting
3231 'NAME COMP_CODE VAL' at a location that dominates block BB or
3232 E->DEST, then register this location as a possible insertion point
3233 for ASSERT_EXPR <NAME, NAME COMP_CODE VAL>.
3235 BB, E and SI provide the exact insertion point for the new
3236 ASSERT_EXPR. If BB is NULL, then the ASSERT_EXPR is to be inserted
3237 on edge E. Otherwise, if E is NULL, the ASSERT_EXPR is inserted on
3238 BB. If SI points to a COND_EXPR or a SWITCH_EXPR statement, then E
3239 must not be NULL. */
3241 static void
3244 tree val,
3245 basic_block bb,
3246 edge e,
3247 block_stmt_iterator si)
3248 {
3251 basic_block dest_bb;
3253 #if defined ENABLE_CHECKING
3259 #endif
3261 /* The new assertion A will be inserted at BB or E. We need to
3262 determine if the new location is dominated by a previously
3263 registered location for A. If we are doing an edge insertion,
3264 assume that A will be inserted at E->DEST. Note that this is not
3265 necessarily true.
3267 If E is a critical edge, it will be split. But even if E is
3268 split, the new block will dominate the same set of blocks that
3269 E->DEST dominates.
3271 The reverse, however, is not true, blocks dominated by E->DEST
3272 will not be dominated by the new block created to split E. So,
3273 if the insertion location is on a critical edge, we will not use
3274 the new location to move another assertion previously registered
3275 at a block dominated by E->DEST. */
3278 /* If NAME already has an ASSERT_EXPR registered for COMP_CODE and
3279 VAL at a block dominating DEST_BB, then we don't need to insert a new
3280 one. Similarly, if the same assertion already exists at a block
3281 dominated by DEST_BB and the new location is not on a critical
3282 edge, then update the existing location for the assertion (i.e.,
3283 move the assertion up in the dominance tree).
3285 Note, this is implemented as a simple linked list because there
3286 should not be more than a handful of assertions registered per
3287 name. If this becomes a performance problem, a table hashed by
3288 COMP_CODE and VAL could be implemented. */
3293 {
3297 {
3298 /* If the assertion NAME COMP_CODE VAL has already been
3299 registered at a basic block that dominates DEST_BB, then
3300 we don't need to insert the same assertion again. Note
3301 that we don't check strict dominance here to avoid
3302 replicating the same assertion inside the same basic
3303 block more than once (e.g., when a pointer is
3304 dereferenced several times inside a block).
3306 An exception to this rule are edge insertions. If the
3307 new assertion is to be inserted on edge E, then it will
3308 dominate all the other insertions that we may want to
3309 insert in DEST_BB. So, if we are doing an edge
3310 insertion, don't do this dominance check. */
3315 /* Otherwise, if E is not a critical edge and DEST_BB
3316 dominates the existing location for the assertion, move
3317 the assertion up in the dominance tree by updating its
3318 location information. */
3321 {
3326 }
3327 }
3329 /* Update the last node of the list and move to the next one. */
3332 }
3334 /* If we didn't find an assertion already registered for
3335 NAME COMP_CODE VAL, add a new one at the end of the list of
3336 assertions associated with NAME. */
3347 else
3351 }
3354 /* Try to register an edge assertion for SSA name NAME on edge E for
3355 the conditional jump pointed to by SI. Return true if an assertion
3356 for NAME could be registered. */
3358 static bool
3360 {
3366 /* Do not attempt to infer anything in names that flow through
3367 abnormal edges. */
3371 /* If NAME was not found in the sub-graph reachable from E, then
3372 there's nothing to do. */
3376 /* We found a use of NAME in the sub-graph rooted at E->DEST.
3377 Register an assertion for NAME according to the value that NAME
3378 takes on edge E. */
3380 {
3381 /* If BB ends in a COND_EXPR then NAME then we should insert
3382 the original predicate on EDGE_TRUE_VALUE and the
3383 opposite predicate on EDGE_FALSE_VALUE. */
3387 /* Predicates may be a single SSA name or NAME OP VAL. */
3389 {
3390 /* If the predicate is a name, it must be NAME, in which
3391 case we create the predicate NAME == true or
3392 NAME == false accordingly. */
3395 }
3396 else
3397 {
3398 /* Otherwise, we have a comparison of the form NAME COMP VAL
3399 or VAL COMP NAME. */
3401 {
3402 /* If the predicate is of the form VAL COMP NAME, flip
3403 COMP around because we need to register NAME as the
3404 first operand in the predicate. */
3407 }
3408 else
3409 {
3410 /* The comparison is of the form NAME COMP VAL, so the
3411 comparison code remains unchanged. */
3414 }
3416 /* If we are inserting the assertion on the ELSE edge, we
3417 need to invert the sign comparison. */
3421 /* Do not register always-false predicates. FIXME, this
3422 works around a limitation in fold() when dealing with
3423 enumerations. Given 'enum { N1, N2 } x;', fold will not
3424 fold 'if (x > N2)' to 'if (0)'. */
3428 {
3437 }
3438 }
3439 }
3440 else
3441 {
3442 /* FIXME. Handle SWITCH_EXPR. */
3444 }
3448 }
3453 /* Determine whether the outgoing edges of BB should receive an
3454 ASSERT_EXPR for each of the operands of BB's last statement. The
3455 last statement of BB must be a COND_EXPR or a SWITCH_EXPR.
3457 If any of the sub-graphs rooted at BB have an interesting use of
3458 the predicate operands, an assert location node is added to the
3459 list of assertions for the corresponding operands. */
3461 static bool
3463 {
3465 block_stmt_iterator last_si;
3467 edge_iterator ei;
3468 edge e;
3469 ssa_op_iter iter;
3475 /* Look for uses of the operands in each of the sub-graphs
3476 rooted at BB. We need to check each of the outgoing edges
3477 separately, so that we know what kind of ASSERT_EXPR to
3478 insert. */
3480 {
3484 /* Remove the COND_EXPR operands from the FOUND_IN_SUBGRAPH bitmap.
3485 Otherwise, when we finish traversing each of the sub-graphs, we
3486 won't know whether the variables were found in the sub-graphs or
3487 if they had been found in a block upstream from BB.
3489 This is actually a bad idea is some cases, particularly jump
3490 threading. Consider a CFG like the following:
3492 0
3493 /|
3494 1 |
3495 \|
3496 2
3497 / \
3498 3 4
3500 Assume that one or more operands in the conditional at the
3501 end of block 0 are used in a conditional in block 2, but not
3502 anywhere in block 1. In this case we will not insert any
3503 assert statements in block 1, which may cause us to miss
3504 opportunities to optimize, particularly for jump threading. */
3508 /* Traverse the strictly dominated sub-graph rooted at E->DEST
3509 to determine if any of the operands in the conditional
3510 predicate are used. */
3514 /* Register the necessary assertions for each operand in the
3515 conditional predicate. */
3518 }
3520 /* Finally, indicate that we have found the operands in the
3521 conditional. */
3526 }
3529 /* Traverse all the statements in block BB looking for statements that
3530 may generate useful assertions for the SSA names in their operand.
3531 If a statement produces a useful assertion A for name N_i, then the
3532 list of assertions already generated for N_i is scanned to
3533 determine if A is actually needed.
3535 If N_i already had the assertion A at a location dominating the
3536 current location, then nothing needs to be done. Otherwise, the
3537 new location for A is recorded instead.
3539 1- For every statement S in BB, all the variables used by S are
3540 added to bitmap FOUND_IN_SUBGRAPH.
3542 2- If statement S uses an operand N in a way that exposes a known
3543 value range for N, then if N was not already generated by an
3544 ASSERT_EXPR, create a new assert location for N. For instance,
3545 if N is a pointer and the statement dereferences it, we can
3546 assume that N is not NULL.
3548 3- COND_EXPRs are a special case of #2. We can derive range
3549 information from the predicate but need to insert different
3550 ASSERT_EXPRs for each of the sub-graphs rooted at the
3551 conditional block. If the last statement of BB is a conditional
3552 expression of the form 'X op Y', then
3554 a) Remove X and Y from the set FOUND_IN_SUBGRAPH.
3556 b) If the conditional is the only entry point to the sub-graph
3557 corresponding to the THEN_CLAUSE, recurse into it. On
3558 return, if X and/or Y are marked in FOUND_IN_SUBGRAPH, then
3559 an ASSERT_EXPR is added for the corresponding variable.
3561 c) Repeat step (b) on the ELSE_CLAUSE.
3563 d) Mark X and Y in FOUND_IN_SUBGRAPH.
3565 For instance,
3567 if (a == 9)
3568 b = a;
3569 else
3570 b = c + 1;
3572 In this case, an assertion on the THEN clause is useful to
3573 determine that 'a' is always 9 on that edge. However, an assertion
3574 on the ELSE clause would be unnecessary.
3576 4- If BB does not end in a conditional expression, then we recurse
3577 into BB's dominator children.
3579 At the end of the recursive traversal, every SSA name will have a
3580 list of locations where ASSERT_EXPRs should be added. When a new
3581 location for name N is found, it is registered by calling
3582 register_new_assert_for. That function keeps track of all the
3583 registered assertions to prevent adding unnecessary assertions.
3584 For instance, if a pointer P_4 is dereferenced more than once in a
3585 dominator tree, only the location dominating all the dereference of
3586 P_4 will receive an ASSERT_EXPR.
3588 If this function returns true, then it means that there are names
3589 for which we need to generate ASSERT_EXPRs. Those assertions are
3590 inserted by process_assert_insertions.
3592 TODO. Handle SWITCH_EXPR. */
3594 static bool
3596 {
3597 block_stmt_iterator si;
3600 basic_block son;
3609 /* Traverse all PHI nodes in BB marking used operands. */
3611 {
3612 use_operand_p arg_p;
3613 ssa_op_iter i;
3616 {
3619 {
3622 }
3623 }
3624 }
3626 /* Traverse all the statements in BB marking used names and looking
3627 for statements that may infer assertions for their used operands. */
3630 {
3632 ssa_op_iter i;
3636 /* See if we can derive an assertion for any of STMT's operands. */
3638 {
3639 tree value;
3642 /* Mark OP in bitmap FOUND_IN_SUBGRAPH. If STMT is inside
3643 the sub-graph of a conditional block, when we return from
3644 this recursive walk, our parent will use the
3645 FOUND_IN_SUBGRAPH bitset to determine if one of the
3646 operands it was looking for was present in the sub-graph. */
3649 /* If OP is used in such a way that we can infer a value
3650 range for it, and we don't find a previous assertion for
3651 it, create a new assertion location node for OP. */
3653 {
3654 /* If we are able to infer a nonzero value range for OP,
3655 then walk backwards through the use-def chain to see if OP
3656 was set via a typecast.
3658 If so, then we can also infer a nonzero value range
3659 for the operand of the NOP_EXPR. */
3661 {
3669 {
3673 /* Note we want to register the assert for the
3674 operand of the NOP_EXPR after SI, not after the
3675 conversion. */
3677 {
3681 }
3682 }
3683 }
3685 /* If OP is used only once, namely in this STMT, don't
3686 bother creating an ASSERT_EXPR for it. Such an
3687 ASSERT_EXPR would do nothing but increase compile time. */
3689 {
3692 }
3693 }
3694 }
3696 /* Remember the last statement of the block. */
3698 }
3700 /* If BB's last statement is a conditional expression
3701 involving integer operands, recurse into each of the sub-graphs
3702 rooted at BB to determine if we need to add ASSERT_EXPRs. */
3709 /* Recurse into the dominator children of BB. */
3711 son;
3716 }
3719 /* Create an ASSERT_EXPR for NAME and insert it in the location
3720 indicated by LOC. Return true if we made any edge insertions. */
3722 static bool
3724 {
3725 /* Build the comparison expression NAME_i COMP_CODE VAL. */
3727 edge_iterator ei;
3728 edge e;
3734 {
3735 /* We have been asked to insert the assertion on an edge. This
3736 is used only by COND_EXPR and SWITCH_EXPR assertions. */
3737 #if defined ENABLE_CHECKING
3740 #endif
3744 }
3746 /* Otherwise, we can insert right after LOC->SI iff the
3747 statement must not be the last statement in the block. */
3750 {
3753 }
3755 /* If STMT must be the last statement in BB, we can only insert new
3756 assertions on the non-abnormal edge out of BB. Note that since
3757 STMT is not control flow, there may only be one non-abnormal edge
3758 out of BB. */
3761 {
3764 }
3767 }
3770 /* Process all the insertions registered for every name N_i registered
3771 in NEED_ASSERT_FOR. The list of assertions to be inserted are
3772 found in ASSERTS_FOR[i]. */
3774 static void
3776 {
3778 bitmap_iterator bi;
3786 {
3791 {
3796 num_asserts++;
3797 }
3798 }
3805 num_asserts);
3806 }
3809 /* Traverse the flowgraph looking for conditional jumps to insert range
3810 expressions. These range expressions are meant to provide information
3811 to optimizations that need to reason in terms of value ranges. They
3812 will not be expanded into RTL. For instance, given:
3814 x = ...
3815 y = ...
3816 if (x < y)
3817 y = x - 2;
3818 else
3819 x = y + 3;
3821 this pass will transform the code into:
3823 x = ...
3824 y = ...
3825 if (x < y)
3826 {
3827 x = ASSERT_EXPR <x, x < y>
3828 y = x - 2
3829 }
3830 else
3831 {
3832 y = ASSERT_EXPR <y, x <= y>
3833 x = y + 3
3834 }
3836 The idea is that once copy and constant propagation have run, other
3837 optimizations will be able to determine what ranges of values can 'x'
3838 take in different paths of the code, simply by checking the reaching
3839 definition of 'x'. */
3841 static void
3843 {
3844 edge e;
3845 edge_iterator ei;
3866 {
3869 }
3872 {
3875 }
3880 }
3883 /* Convert range assertion expressions into the implied copies and
3884 copy propagate away the copies. Doing the trivial copy propagation
3885 here avoids the need to run the full copy propagation pass after
3886 VRP.
3888 FIXME, this will eventually lead to copy propagation removing the
3889 names that had useful range information attached to them. For
3890 instance, if we had the assertion N_i = ASSERT_EXPR <N_j, N_j > 3>,
3891 then N_i will have the range [3, +INF].
3893 However, by converting the assertion into the implied copy
3894 operation N_i = N_j, we will then copy-propagate N_j into the uses
3895 of N_i and lose the range information. We may want to hold on to
3896 ASSERT_EXPRs a little while longer as the ranges could be used in
3897 things like jump threading.
3899 The problem with keeping ASSERT_EXPRs around is that passes after
3900 VRP need to handle them appropriately.
3902 Another approach would be to make the range information a first
3903 class property of the SSA_NAME so that it can be queried from
3904 any pass. This is made somewhat more complex by the need for
3905 multiple ranges to be associated with one SSA_NAME. */
3907 static void
3909 {
3910 basic_block bb;
3911 block_stmt_iterator si;
3913 /* Note that the BSI iterator bump happens at the bottom of the
3914 loop and no bump is necessary if we're removing the statement
3915 referenced by the current BSI. */
3918 {
3920 tree use_stmt;
3924 {
3927 use_operand_p use_p;
3928 imm_use_iterator iter;
3932 /* Propagate the RHS into every use of the LHS. */
3936 {
3939 }
3941 /* And finally, remove the copy, it is not needed. */
3943 }
3944 else
3946 }
3949 }
3952 /* Return true if STMT is interesting for VRP. */
3954 static bool
3956 {
3963 {
3967 /* In general, assignments with virtual operands are not useful
3968 for deriving ranges, with the obvious exception of calls to
3969 builtin functions. */
3979 }
3984 }
3987 /* Initialize local data structures for VRP. */
3989 static void
3991 {
3992 basic_block bb;
3998 {
3999 block_stmt_iterator si;
4000 tree phi;
4003 {
4005 {
4009 }
4010 else
4012 }
4015 {
4019 {
4020 ssa_op_iter i;
4021 tree def;
4025 }
4026 else
4027 {
4029 }
4030 }
4031 }
4032 }
4035 /* Visit assignment STMT. If it produces an interesting range, record
4036 the SSA name in *OUTPUT_P. */
4038 static enum ssa_prop_result
4040 {
4042 ssa_op_iter iter;
4047 /* We only keep track of ranges in integral and pointer types. */
4050 /* It is valid to have NULL MIN/MAX values on a type. See
4051 build_range_type. */
4055 {
4061 /* If STMT is inside a loop, we may be able to know something
4062 else about the range of LHS by examining scalar evolution
4063 information. */
4068 {
4072 {
4078 }
4084 }
4087 }
4089 /* Every other statement produces no useful ranges. */
4094 }
4097 /* Compare all the value ranges for names equivalent to VAR with VAL
4098 using comparison code COMP. Return the same value returned by
4099 compare_range_with_value, including the setting of
4100 *STRICT_OVERFLOW_P. */
4102 static tree
4105 {
4106 bitmap_iterator bi;
4108 bitmap e;
4114 /* Get the set of equivalences for VAR. */
4117 /* Add VAR to its own set of equivalences so that VAR's value range
4118 is processed by this loop (otherwise, we would have to replicate
4119 the body of the loop just to check VAR's value range). */
4122 /* Start at -1. Set it to 0 if we do a comparison without relying
4123 on overflow, or 1 if all comparisons rely on overflow. */
4127 {
4132 /* If name N_i does not have a valid range, use N_i as its own
4133 range. This allows us to compare against names that may
4134 have N_i in their ranges. */
4136 {
4140 }
4145 {
4146 /* If we get different answers from different members
4147 of the equivalence set this check must be in a dead
4148 code region. Folding it to a trap representation
4149 would be correct here. For now just return don't-know. */
4152 {
4155 }
4162 }
4163 }
4165 /* Remove VAR from its own equivalence set. */
4169 {
4173 }
4175 /* We couldn't find a non-NULL value for the predicate. */
4177 }
4180 /* Given a comparison code COMP and names N1 and N2, compare all the
4181 ranges equivalent to N1 against all the ranges equivalent to N2
4182 to determine the value of N1 COMP N2. Return the same value
4183 returned by compare_ranges. Set *STRICT_OVERFLOW_P to indicate
4184 whether we relied on an overflow infinity in the comparison. */
4187 static tree
4190 {
4197 /* Compare the ranges of every name equivalent to N1 against the
4198 ranges of every name equivalent to N2. */
4202 /* Add N1 and N2 to their own set of equivalences to avoid
4203 duplicating the body of the loop just to check N1 and N2
4204 ranges. */
4208 /* If the equivalence sets have a common intersection, then the two
4209 names can be compared without checking their ranges. */
4211 {
4216 ? boolean_true_node
4218 }
4220 /* Start at -1. Set it to 0 if we do a comparison without relying
4221 on overflow, or 1 if all comparisons rely on overflow. */
4224 /* Otherwise, compare all the equivalent ranges. First, add N1 and
4225 N2 to their own set of equivalences to avoid duplicating the body
4226 of the loop just to check N1 and N2 ranges. */
4228 {
4231 /* If the range is VARYING or UNDEFINED, use the name itself. */
4233 {
4237 }
4241 {
4247 {
4251 }
4255 {
4256 /* If we get different answers from different members
4257 of the equivalence set this check must be in a dead
4258 code region. Folding it to a trap representation
4259 would be correct here. For now just return don't-know. */
4262 {
4266 }
4273 }
4274 }
4277 {
4283 }
4284 }
4286 /* None of the equivalent ranges are useful in computing this
4287 comparison. */
4291 }
4294 /* Given a conditional predicate COND, try to determine if COND yields
4295 true or false based on the value ranges of its operands. Return
4296 BOOLEAN_TRUE_NODE if the conditional always evaluates to true,
4297 BOOLEAN_FALSE_NODE if the conditional always evaluates to false, and,
4298 NULL if the conditional cannot be evaluated at compile time.
4300 If USE_EQUIV_P is true, the ranges of all the names equivalent with
4301 the operands in COND are used when trying to compute its value.
4302 This is only used during final substitution. During propagation,
4303 we only check the range of each variable and not its equivalents.
4305 Set *STRICT_OVERFLOW_P to indicate whether we relied on an overflow
4306 infinity to produce the result. */
4308 static tree
4311 {
4316 {
4318 tree retval;
4322 strict_overflow_p);
4323 else
4324 {
4327 strict_overflow_p);
4328 }
4330 /* If COND has a known boolean range, return it. */
4334 /* Otherwise, if COND has a symbolic range of exactly one value,
4335 return it. */
4339 }
4340 else
4341 {
4345 /* We only deal with integral and pointer types. */
4351 {
4354 strict_overflow_p);
4357 strict_overflow_p);
4361 strict_overflow_p));
4362 }
4363 else
4364 {
4372 strict_overflow_p);
4375 strict_overflow_p);
4379 strict_overflow_p));
4380 }
4381 }
4383 /* Anything else cannot be computed statically. */
4385 }
4387 /* Given COND within STMT, try to simplify it based on value range
4388 information. Return NULL if the conditional can not be evaluated.
4389 The ranges of all the names equivalent with the operands in COND
4390 will be used when trying to compute the value. If the result is
4391 based on undefined signed overflow, issue a warning if
4392 appropriate. */
4394 tree
4396 {
4398 tree ret;
4404 {
4409 {
4413 }
4414 else
4415 {
4419 }
4422 {
4423 location_t locus;
4427 else
4430 }
4431 }
4434 }
4437 /* Visit conditional statement STMT. If we can determine which edge
4438 will be taken out of STMT's basic block, record it in
4439 *TAKEN_EDGE_P and return SSA_PROP_INTERESTING. Otherwise, return
4440 SSA_PROP_VARYING. */
4442 static enum ssa_prop_result
4444 {
4450 /* FIXME. Handle SWITCH_EXPRs. But first, the assert pass needs to
4451 add ASSERT_EXPRs for them. */
4458 {
4459 tree use;
4460 ssa_op_iter i;
4467 {
4472 }
4475 }
4477 /* Compute the value of the predicate COND by checking the known
4478 ranges of each of its operands.
4480 Note that we cannot evaluate all the equivalent ranges here
4481 because those ranges may not yet be final and with the current
4482 propagation strategy, we cannot determine when the value ranges
4483 of the names in the equivalence set have changed.
4485 For instance, given the following code fragment
4487 i_5 = PHI <8, i_13>
4488 ...
4489 i_14 = ASSERT_EXPR <i_5, i_5 != 0>
4490 if (i_14 == 1)
4491 ...
4493 Assume that on the first visit to i_14, i_5 has the temporary
4494 range [8, 8] because the second argument to the PHI function is
4495 not yet executable. We derive the range ~[0, 0] for i_14 and the
4496 equivalence set { i_5 }. So, when we visit 'if (i_14 == 1)' for
4497 the first time, since i_14 is equivalent to the range [8, 8], we
4498 determine that the predicate is always false.
4500 On the next round of propagation, i_13 is determined to be
4501 VARYING, which causes i_5 to drop down to VARYING. So, another
4502 visit to i_14 is scheduled. In this second visit, we compute the
4503 exact same range and equivalence set for i_14, namely ~[0, 0] and
4504 { i_5 }. But we did not have the previous range for i_5
4505 registered, so vrp_visit_assignment thinks that the range for
4506 i_14 has not changed. Therefore, the predicate 'if (i_14 == 1)'
4507 is not visited again, which stops propagation from visiting
4508 statements in the THEN clause of that if().
4510 To properly fix this we would need to keep the previous range
4511 value for the names in the equivalence set. This way we would've
4512 discovered that from one visit to the other i_5 changed from
4513 range [8, 8] to VR_VARYING.
4515 However, fixing this apparent limitation may not be worth the
4516 additional checking. Testing on several code bases (GCC, DLV,
4517 MICO, TRAMP3D and SPEC2000) showed that doing this results in
4518 4 more predicates folded in SPEC. */
4522 {
4525 else
4526 {
4532 }
4533 }
4536 {
4540 else
4542 }
4545 }
4548 /* Evaluate statement STMT. If the statement produces a useful range,
4549 return SSA_PROP_INTERESTING and record the SSA name with the
4550 interesting range into *OUTPUT_P.
4552 If STMT is a conditional branch and we can determine its truth
4553 value, the taken edge is recorded in *TAKEN_EDGE_P.
4555 If STMT produces a varying value, return SSA_PROP_VARYING. */
4557 static enum ssa_prop_result
4559 {
4560 tree def;
4561 ssa_op_iter iter;
4562 stmt_ann_t ann;
4565 {
4569 }
4573 {
4576 /* In general, assignments with virtual operands are not useful
4577 for deriving ranges, with the obvious exception of calls to
4578 builtin functions. */
4585 }
4589 /* All other statements produce nothing of interest for VRP, so mark
4590 their outputs varying and prevent further simulation. */
4595 }
4598 /* Meet operation for value ranges. Given two value ranges VR0 and
4599 VR1, store in VR0 the result of meeting VR0 and VR1.
4601 The meeting rules are as follows:
4603 1- If VR0 and VR1 have an empty intersection, set VR0 to VR_VARYING.
4605 2- If VR0 and VR1 have a non-empty intersection, set VR0 to the
4606 union of VR0 and VR1. */
4608 static void
4610 {
4612 {
4615 }
4618 {
4619 /* Nothing to do. VR0 already has the resulting range. */
4621 }
4624 {
4625 /* Nothing to do. VR0 already has the resulting range. */
4627 }
4630 {
4633 }
4636 {
4637 /* If VR0 and VR1 have a non-empty intersection, compute the
4638 union of both ranges. */
4640 {
4644 /* The lower limit of the new range is the minimum of the
4645 two ranges. If they cannot be compared, the result is
4646 VARYING. */
4652 else
4653 {
4656 }
4658 /* Similarly, the upper limit of the new range is the
4659 maximum of the two ranges. If they cannot be compared,
4660 the result is VARYING. */
4666 else
4667 {
4670 }
4672 /* Check for useless ranges. */
4676 {
4679 }
4681 /* The resulting set of equivalences is the intersection of
4682 the two sets. */
4689 }
4690 else
4692 }
4694 {
4695 /* Two anti-ranges meet only if they are both identical. */
4699 {
4700 /* The resulting set of equivalences is the intersection of
4701 the two sets. */
4706 }
4707 else
4709 }
4711 {
4712 /* A numeric range [VAL1, VAL2] and an anti-range ~[VAL3, VAL4]
4713 meet only if the ranges have an empty intersection. The
4714 result of the meet operation is the anti-range. */
4718 {
4719 /* Copy most of VR1 into VR0. Don't copy VR1's equivalence
4720 set. We need to compute the intersection of the two
4721 equivalence sets. */
4725 /* The resulting set of equivalences is the intersection of
4726 the two sets. */
4731 }
4732 else
4734 }
4735 else
4740 no_meet:
4741 /* The two range VR0 and VR1 do not meet. Before giving up and
4742 setting the result to VARYING, see if we can at least derive a
4743 useful anti-range. FIXME, all this nonsense about distinguishing
4744 anti-ranges from ranges is necessary because of the odd
4745 semantics of range_includes_zero_p and friends. */
4752 {
4755 /* Since this meet operation did not result from the meeting of
4756 two equivalent names, VR0 cannot have any equivalences. */
4759 }
4760 else
4762 }
4765 /* Visit all arguments for PHI node PHI that flow through executable
4766 edges. If a valid value range can be derived from all the incoming
4767 value ranges, set a new range for the LHS of PHI. */
4769 static enum ssa_prop_result
4771 {
4780 {
4783 }
4786 {
4790 {
4795 }
4798 {
4800 value_range_t vr_arg;
4804 else
4805 {
4807 {
4810 }
4816 }
4819 {
4825 }
4831 }
4832 }
4837 /* To prevent infinite iterations in the algorithm, derive ranges
4838 when the new value is slightly bigger or smaller than the
4839 previous one. */
4841 {
4843 {
4847 /* If the new minimum is smaller or larger than the previous
4848 one, go all the way to -INF. In the first case, to avoid
4849 iterating millions of times to reach -INF, and in the
4850 other case to avoid infinite bouncing between different
4851 minimums. */
4853 {
4854 /* If we will end up with a (-INF, +INF) range, set it
4855 to VARYING. */
4865 else
4867 }
4869 /* Similarly, if the new maximum is smaller or larger than
4870 the previous one, go all the way to +INF. */
4872 {
4873 /* If we will end up with a (-INF, +INF) range, set it
4874 to VARYING. */
4884 else
4886 }
4887 }
4888 }
4890 /* If the new range is different than the previous value, keep
4891 iterating. */
4895 /* Nothing changed, don't add outgoing edges. */
4898 /* No match found. Set the LHS to VARYING. */
4899 varying:
4902 }
4904 /* Simplify a division or modulo operator to a right shift or
4905 bitwise and if the first operand is unsigned or is greater
4906 than zero and the second operand is an exact power of two. */
4908 static void
4910 {
4916 {
4918 }
4919 else
4920 {
4926 && sop
4929 {
4930 location_t locus;
4934 else
4940 }
4941 }
4944 {
4945 tree t;
4950 {
4953 }
4954 else
4955 {
4960 }
4964 }
4965 }
4967 /* If the operand to an ABS_EXPR is >= 0, then eliminate the
4968 ABS_EXPR. If the operand is <= 0, then simplify the
4969 ABS_EXPR into a NEGATE_EXPR. */
4971 static void
4973 {
4980 {
4982 }
4984 {
4989 {
4995 {
5000 }
5001 }
5005 {
5006 tree t;
5009 {
5010 location_t locus;
5014 else
5020 }
5024 else
5029 }
5030 }
5031 }
5033 /* We are comparing trees OP0 and OP1 using COND_CODE. OP0 has
5034 a known value range VR.
5036 If there is one and only one value which will satisfy the
5037 conditional, then return that value. Else return NULL. */
5039 static tree
5042 {
5046 /* Extract minimum/maximum values which satisfy the
5047 the conditional as it was written. */
5049 {
5050 /* This should not be negative infinity; there is no overflow
5051 here. */
5056 {
5061 }
5062 }
5064 {
5065 /* This should not be positive infinity; there is no overflow
5066 here. */
5071 {
5076 }
5077 }
5079 /* Now refine the minimum and maximum values using any
5080 value range information we have for op0. */
5082 {
5085 else
5089 else
5092 /* If the new min/max values have converged to a single value,
5093 then there is only one value which can satisfy the condition,
5094 return that value. */
5097 }
5099 }
5101 /* Simplify a conditional using a relational operator to an equality
5102 test if the range information indicates only one value can satisfy
5103 the original conditional. */
5105 static void
5107 {
5118 {
5121 /* If we have range information for OP0, then we might be
5122 able to simplify this conditional. */
5124 {
5128 {
5130 {
5134 }
5141 {
5144 }
5147 }
5149 /* Try again after inverting the condition. We only deal
5150 with integral types here, so no need to worry about
5151 issues with inverting FP comparisons. */
5156 {
5158 {
5162 }
5169 {
5172 }
5175 }
5176 }
5177 }
5178 }
5180 /* Simplify STMT using ranges if possible. */
5182 void
5184 {
5186 {
5190 /* Transform TRUNC_DIV_EXPR and TRUNC_MOD_EXPR into RSHIFT_EXPR
5191 and BIT_AND_EXPR respectively if the first operand is greater
5192 than zero and the second operand is an exact power of two. */
5198 /* Transform ABS (X) into X or -X as appropriate. */
5203 }
5206 {
5208 }
5209 }
5211 /* Stack of dest,src equivalency pairs that need to be restored after
5212 each attempt to thread a block's incoming edge to an outgoing edge.
5214 A NULL entry is used to mark the end of pairs which need to be
5215 restored. */
5218 /* A trivial wrapper so that we can present the generic jump threading
5219 code with a simple API for simplifying statements. STMT is the
5220 statement we want to simplify, WITHIN_STMT provides the location
5221 for any overflow warnings. */
5223 static tree
5225 {
5226 /* We only use VRP information to simplify conditionals. This is
5227 overly conservative, but it's unclear if doing more would be
5228 worth the compile time cost. */
5233 }
5235 /* Blocks which have more than one predecessor and more than
5236 one successor present jump threading opportunities. ie,
5237 when the block is reached from a specific predecessor, we
5238 may be able to determine which of the outgoing edges will
5239 be traversed. When this optimization applies, we are able
5240 to avoid conditionals at runtime and we may expose secondary
5241 optimization opportunities.
5243 This routine is effectively a driver for the generic jump
5244 threading code. It basically just presents the generic code
5245 with edges that may be suitable for jump threading.
5247 Unlike DOM, we do not iterate VRP if jump threading was successful.
5248 While iterating may expose new opportunities for VRP, it is expected
5249 those opportunities would be very limited and the compile time cost
5250 to expose those opportunities would be significant.
5252 As jump threading opportunities are discovered, they are registered
5253 for later realization. */
5255 static void
5257 {
5258 basic_block bb;
5259 tree dummy;
5261 /* Ugh. When substituting values earlier in this pass we can
5262 wipe the dominance information. So rebuild the dominator
5263 information as we need it within the jump threading code. */
5266 /* We do not allow VRP information to be used for jump threading
5267 across a back edge in the CFG. Otherwise it becomes too
5268 difficult to avoid eliminating loop exit tests. Of course
5269 EDGE_DFS_BACK is not accurate at this time so we have to
5270 recompute it. */
5273 /* Allocate our unwinder stack to unwind any temporary equivalences
5274 that might be recorded. */
5277 /* To avoid lots of silly node creation, we create a single
5278 conditional and just modify it in-place when attempting to
5279 thread jumps. */
5283 /* Walk through all the blocks finding those which present a
5284 potential jump threading opportunity. We could set this up
5285 as a dominator walker and record data during the walk, but
5286 I doubt it's worth the effort for the classes of jump
5287 threading opportunities we are trying to identify at this
5288 point in compilation. */
5290 {
5293 /* If the generic jump threading code does not find this block
5294 interesting, then there is nothing to do. */
5298 /* We only care about blocks ending in a COND_EXPR. While there
5299 may be some value in handling SWITCH_EXPR here, I doubt it's
5300 terribly important. */
5305 /* We're basically looking for any kind of conditional with
5306 integral type arguments. */
5316 {
5317 edge_iterator ei;
5318 edge e;
5320 /* We've got a block with multiple predecessors and multiple
5321 successors which also ends in a suitable conditional. For
5322 each predecessor, see if we can thread it to a specific
5323 successor. */
5325 {
5326 /* Do not thread across back edges or abnormal edges
5327 in the CFG. */
5333 simplify_stmt_for_jump_threading);
5334 }
5335 }
5336 }
5338 /* We do not actually update the CFG or SSA graphs at this point as
5339 ASSERT_EXPRs are still in the IL and cfg cleanup code does not yet
5340 handle ASSERT_EXPRs gracefully. */
5341 }
5343 /* We identified all the jump threading opportunities earlier, but could
5344 not transform the CFG at that time. This routine transforms the
5345 CFG and arranges for the dominator tree to be rebuilt if necessary.
5347 Note the SSA graph update will occur during the normal TODO
5348 processing by the pass manager. */
5349 static void
5351 {
5355 /* If we threaded jumps, then we need to recompute the dominance
5356 information, to safely do that we must clean up the CFG first. */
5358 {
5362 }
5364 }
5367 /* Traverse all the blocks folding conditionals with known ranges. */
5369 static void
5371 {
5377 {
5381 }
5383 /* We may have ended with ranges that have exactly one value. Those
5384 values can be substituted as any other copy/const propagated
5385 value using substitute_and_fold. */
5394 {
5397 }
5400 {
5401 /* We found no single-valued ranges, don't waste time trying to
5402 do single value substitution in substitute_and_fold. */
5405 }
5409 /* We must identify jump threading opportunities before we release
5410 the datastructures built by VRP. */
5413 /* Free allocated memory. */
5416 {
5419 }
5424 /* So that we can distinguish between VRP data being available
5425 and not available. */
5427 }
5430 /* Main entry point to VRP (Value Range Propagation). This pass is
5431 loosely based on J. R. C. Patterson, ``Accurate Static Branch
5432 Prediction by Value Range Propagation,'' in SIGPLAN Conference on
5433 Programming Language Design and Implementation, pp. 67-78, 1995.
5434 Also available at http://citeseer.ist.psu.edu/patterson95accurate.html
5436 This is essentially an SSA-CCP pass modified to deal with ranges
5437 instead of constants.
5439 While propagating ranges, we may find that two or more SSA name
5440 have equivalent, though distinct ranges. For instance,
5442 1 x_9 = p_3->a;
5443 2 p_4 = ASSERT_EXPR <p_3, p_3 != 0>
5444 3 if (p_4 == q_2)
5445 4 p_5 = ASSERT_EXPR <p_4, p_4 == q_2>;
5446 5 endif
5447 6 if (q_2)
5449 In the code above, pointer p_5 has range [q_2, q_2], but from the
5450 code we can also determine that p_5 cannot be NULL and, if q_2 had
5451 a non-varying range, p_5's range should also be compatible with it.
5453 These equivalences are created by two expressions: ASSERT_EXPR and
5454 copy operations. Since p_5 is an assertion on p_4, and p_4 was the
5455 result of another assertion, then we can use the fact that p_5 and
5456 p_4 are equivalent when evaluating p_5's range.
5458 Together with value ranges, we also propagate these equivalences
5459 between names so that we can take advantage of information from
5460 multiple ranges when doing final replacement. Note that this
5461 equivalency relation is transitive but not symmetric.
5463 In the example above, p_5 is equivalent to p_4, q_2 and p_3, but we
5464 cannot assert that q_2 is equivalent to p_5 because q_2 may be used
5465 in contexts where that assertion does not hold (e.g., in line 6).
5467 TODO, the main difference between this pass and Patterson's is that
5468 we do not propagate edge probabilities. We only compute whether
5469 edges can be taken or not. That is, instead of having a spectrum
5470 of jump probabilities between 0 and 1, we only deal with 0, 1 and
5471 DON'T KNOW. In the future, it may be worthwhile to propagate
5472 probabilities to aid branch prediction. */
5474 static unsigned int
5476 {
5488 {
5492 }
5494 /* ASSERT_EXPRs must be removed before finalizing jump threads
5495 as finalizing jump threads calls the CFG cleanup code which
5496 does not properly handle ASSERT_EXPRs. */
5499 /* If we exposed any new variables, go ahead and put them into
5500 SSA form now, before we handle jump threading. This simplifies
5501 interactions between rewriting of _DECL nodes into SSA form
5502 and rewriting SSA_NAME nodes into SSA form after block
5503 duplication and CFG manipulation. */
5508 }
5510 static bool
5512 {
5514 }
5517 {
5529 TODO_cleanup_cfg
5530 | TODO_ggc_collect
5531 | TODO_verify_ssa
5532 | TODO_dump_func
5533 | TODO_update_ssa
5536 };