| blob | 4626485191ff55f24ade078253ccdc4e2f00a8be |
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. */
2512 /* We use TYPE_MIN_VALUE and TYPE_MAX_VALUE here instead of
2513 negative_overflow_infinity and positive_overflow_infinity,
2514 because we have concluded that the loop probably does not
2515 wrap. */
2520 else
2524 else
2528 {
2532 /* For VARYING or UNDEFINED ranges, just about anything we get
2533 from scalar evolutions should be better. */
2537 else
2540 /* If we would create an invalid range, then just assume we
2541 know absolutely nothing. This may be over-conservative,
2542 but it's clearly safe, and should happen only in unreachable
2543 parts of code, or for invalid programs. */
2548 }
2550 {
2555 {
2556 /* INIT is the maximum value. If INIT is lower than VR->MAX
2557 but no smaller than VR->MIN, set VR->MAX to INIT. */
2559 {
2562 /* If we just created an invalid range with the minimum
2563 greater than the maximum, we fail conservatively.
2564 This should happen only in unreachable
2565 parts of code, or for invalid programs. */
2568 }
2570 /* According to the loop information, the variable does not
2571 overflow. If we think it does, probably because of an
2572 overflow due to arithmetic on a different INF value,
2573 reset now. */
2576 }
2577 else
2578 {
2579 /* If INIT is bigger than VR->MIN, set VR->MIN to INIT. */
2581 {
2584 /* Again, avoid creating invalid range by failing. */
2587 }
2591 }
2594 }
2595 }
2597 /* Return true if VAR may overflow at STMT. This checks any available
2598 loop information to see if we can determine that VAR does not
2599 overflow. */
2601 static bool
2603 {
2626 /* If we get here, we know something useful about VAR based on the
2627 loop information. If it wraps, it may overflow. */
2635 {
2638 }
2641 }
2644 /* Given two numeric value ranges VR0, VR1 and a comparison code COMP:
2646 - Return BOOLEAN_TRUE_NODE if VR0 COMP VR1 always returns true for
2647 all the values in the ranges.
2649 - Return BOOLEAN_FALSE_NODE if the comparison always returns false.
2651 - Return NULL_TREE if it is not always possible to determine the
2652 value of the comparison.
2654 Also set *STRICT_OVERFLOW_P to indicate whether a range with an
2655 overflow infinity was used in the test. */
2658 static tree
2661 {
2662 /* VARYING or UNDEFINED ranges cannot be compared. */
2669 /* Anti-ranges need to be handled separately. */
2671 {
2672 /* If both are anti-ranges, then we cannot compute any
2673 comparison. */
2677 /* These comparisons are never statically computable. */
2684 /* Equality can be computed only between a range and an
2685 anti-range. ~[VAL1, VAL2] == [VAL1, VAL2] is always false. */
2687 {
2688 /* To simplify processing, make VR0 the anti-range. */
2692 }
2701 }
2707 /* Simplify processing. If COMP is GT_EXPR or GE_EXPR, switch the
2708 operands around and change the comparison code. */
2710 {
2716 }
2719 {
2720 /* Equality may only be computed if both ranges represent
2721 exactly one value. */
2724 {
2726 strict_overflow_p);
2728 strict_overflow_p);
2733 }
2734 /* If [V0_MIN, V1_MAX] < [V1_MIN, V1_MAX] then V0 != V1. */
2742 }
2744 {
2747 /* If VR0 is completely to the left or completely to the right
2748 of VR1, they are always different. Notice that we need to
2749 make sure that both comparisons yield similar results to
2750 avoid comparing values that cannot be compared at
2751 compile-time. */
2757 /* If VR0 and VR1 represent a single value and are identical,
2758 return false. */
2769 /* Otherwise, they may or may not be different. */
2770 else
2772 }
2774 {
2777 /* If VR0 is to the left of VR1, return true. */
2781 {
2786 }
2788 /* If VR0 is to the right of VR1, return false. */
2792 {
2797 }
2799 /* Otherwise, we don't know. */
2801 }
2804 }
2807 /* Given a value range VR, a value VAL and a comparison code COMP, return
2808 BOOLEAN_TRUE_NODE if VR COMP VAL always returns true for all the
2809 values in VR. Return BOOLEAN_FALSE_NODE if the comparison
2810 always returns false. Return NULL_TREE if it is not always
2811 possible to determine the value of the comparison. Also set
2812 *STRICT_OVERFLOW_P to indicate whether a range with an overflow
2813 infinity was used in the test. */
2815 static tree
2818 {
2822 /* Anti-ranges need to be handled separately. */
2824 {
2825 /* For anti-ranges, the only predicates that we can compute at
2826 compile time are equality and inequality. */
2833 /* ~[VAL_1, VAL_2] OP VAL is known if VAL_1 <= VAL <= VAL_2. */
2838 }
2844 {
2845 /* EQ_EXPR may only be computed if VR represents exactly
2846 one value. */
2848 {
2854 }
2860 }
2862 {
2863 /* If VAL is not inside VR, then they are always different. */
2868 /* If VR represents exactly one value equal to VAL, then return
2869 false. */
2874 /* Otherwise, they may or may not be different. */
2876 }
2878 {
2881 /* If VR is to the left of VAL, return true. */
2885 {
2889 }
2891 /* If VR is to the right of VAL, return false. */
2895 {
2899 }
2901 /* Otherwise, we don't know. */
2903 }
2905 {
2908 /* If VR is to the right of VAL, return true. */
2912 {
2916 }
2918 /* If VR is to the left of VAL, return false. */
2922 {
2926 }
2928 /* Otherwise, we don't know. */
2930 }
2933 }
2936 /* Debugging dumps. */
2946 /* Dump value range VR to FILE. */
2948 void
2950 {
2956 {
2967 else
2977 else
2983 {
2984 bitmap_iterator bi;
2990 {
2993 c++;
2994 }
2997 }
2998 }
3001 else
3003 }
3006 /* Dump value range VR to stderr. */
3008 void
3010 {
3013 }
3016 /* Dump value ranges of all SSA_NAMEs to FILE. */
3018 void
3020 {
3024 {
3026 {
3031 }
3032 }
3035 }
3038 /* Dump all value ranges to stderr. */
3040 void
3042 {
3044 }
3047 /* Given a COND_EXPR COND of the form 'V OP W', and an SSA name V,
3048 create a new SSA name N and return the assertion assignment
3049 'V = ASSERT_EXPR <V, V OP W>'. */
3051 static tree
3053 {
3060 {
3063 }
3065 {
3066 /* Given !V, build the assignment N = false. */
3070 }
3072 {
3073 /* Given V, build the assignment N = true. */
3076 }
3077 else
3082 /* The new ASSERT_EXPR, creates a new SSA name that replaces the
3083 operand of the ASSERT_EXPR. Register the new name and the old one
3084 in the replacement table so that we can fix the SSA web after
3085 adding all the ASSERT_EXPRs. */
3089 }
3092 /* Return false if EXPR is a predicate expression involving floating
3093 point values. */
3097 {
3100 }
3103 /* If the range of values taken by OP can be inferred after STMT executes,
3104 return the comparison code (COMP_CODE_P) and value (VAL_P) that
3105 describes the inferred range. Return true if a range could be
3106 inferred. */
3108 static bool
3110 {
3114 /* Do not attempt to infer anything in names that flow through
3115 abnormal edges. */
3119 /* Similarly, don't infer anything from statements that may throw
3120 exceptions. */
3124 /* If STMT is the last statement of a basic block with no
3125 successors, there is no point inferring anything about any of its
3126 operands. We would not be able to find a proper insertion point
3127 for the assertion, anyway. */
3131 /* We can only assume that a pointer dereference will yield
3132 non-NULL if -fdelete-null-pointer-checks is enabled. */
3134 {
3140 {
3144 }
3145 }
3148 }
3156 /* Dump all the registered assertions for NAME to FILE. */
3158 void
3160 {
3161 assert_locus_t loc;
3169 {
3174 {
3178 }
3185 }
3188 }
3191 /* Dump all the registered assertions for NAME to stderr. */
3193 void
3195 {
3197 }
3200 /* Dump all the registered assertions for all the names to FILE. */
3202 void
3204 {
3206 bitmap_iterator bi;
3212 }
3215 /* Dump all the registered assertions for all the names to stderr. */
3217 void
3219 {
3221 }
3224 /* If NAME doesn't have an ASSERT_EXPR registered for asserting
3225 'NAME COMP_CODE VAL' at a location that dominates block BB or
3226 E->DEST, then register this location as a possible insertion point
3227 for ASSERT_EXPR <NAME, NAME COMP_CODE VAL>.
3229 BB, E and SI provide the exact insertion point for the new
3230 ASSERT_EXPR. If BB is NULL, then the ASSERT_EXPR is to be inserted
3231 on edge E. Otherwise, if E is NULL, the ASSERT_EXPR is inserted on
3232 BB. If SI points to a COND_EXPR or a SWITCH_EXPR statement, then E
3233 must not be NULL. */
3235 static void
3238 tree val,
3239 basic_block bb,
3240 edge e,
3241 block_stmt_iterator si)
3242 {
3245 basic_block dest_bb;
3247 #if defined ENABLE_CHECKING
3253 #endif
3255 /* The new assertion A will be inserted at BB or E. We need to
3256 determine if the new location is dominated by a previously
3257 registered location for A. If we are doing an edge insertion,
3258 assume that A will be inserted at E->DEST. Note that this is not
3259 necessarily true.
3261 If E is a critical edge, it will be split. But even if E is
3262 split, the new block will dominate the same set of blocks that
3263 E->DEST dominates.
3265 The reverse, however, is not true, blocks dominated by E->DEST
3266 will not be dominated by the new block created to split E. So,
3267 if the insertion location is on a critical edge, we will not use
3268 the new location to move another assertion previously registered
3269 at a block dominated by E->DEST. */
3272 /* If NAME already has an ASSERT_EXPR registered for COMP_CODE and
3273 VAL at a block dominating DEST_BB, then we don't need to insert a new
3274 one. Similarly, if the same assertion already exists at a block
3275 dominated by DEST_BB and the new location is not on a critical
3276 edge, then update the existing location for the assertion (i.e.,
3277 move the assertion up in the dominance tree).
3279 Note, this is implemented as a simple linked list because there
3280 should not be more than a handful of assertions registered per
3281 name. If this becomes a performance problem, a table hashed by
3282 COMP_CODE and VAL could be implemented. */
3287 {
3291 {
3292 /* If the assertion NAME COMP_CODE VAL has already been
3293 registered at a basic block that dominates DEST_BB, then
3294 we don't need to insert the same assertion again. Note
3295 that we don't check strict dominance here to avoid
3296 replicating the same assertion inside the same basic
3297 block more than once (e.g., when a pointer is
3298 dereferenced several times inside a block).
3300 An exception to this rule are edge insertions. If the
3301 new assertion is to be inserted on edge E, then it will
3302 dominate all the other insertions that we may want to
3303 insert in DEST_BB. So, if we are doing an edge
3304 insertion, don't do this dominance check. */
3309 /* Otherwise, if E is not a critical edge and DEST_BB
3310 dominates the existing location for the assertion, move
3311 the assertion up in the dominance tree by updating its
3312 location information. */
3315 {
3320 }
3321 }
3323 /* Update the last node of the list and move to the next one. */
3326 }
3328 /* If we didn't find an assertion already registered for
3329 NAME COMP_CODE VAL, add a new one at the end of the list of
3330 assertions associated with NAME. */
3341 else
3345 }
3348 /* Try to register an edge assertion for SSA name NAME on edge E for
3349 the conditional jump pointed to by SI. Return true if an assertion
3350 for NAME could be registered. */
3352 static bool
3354 {
3360 /* Do not attempt to infer anything in names that flow through
3361 abnormal edges. */
3365 /* If NAME was not found in the sub-graph reachable from E, then
3366 there's nothing to do. */
3370 /* We found a use of NAME in the sub-graph rooted at E->DEST.
3371 Register an assertion for NAME according to the value that NAME
3372 takes on edge E. */
3374 {
3375 /* If BB ends in a COND_EXPR then NAME then we should insert
3376 the original predicate on EDGE_TRUE_VALUE and the
3377 opposite predicate on EDGE_FALSE_VALUE. */
3381 /* Predicates may be a single SSA name or NAME OP VAL. */
3383 {
3384 /* If the predicate is a name, it must be NAME, in which
3385 case we create the predicate NAME == true or
3386 NAME == false accordingly. */
3389 }
3390 else
3391 {
3392 /* Otherwise, we have a comparison of the form NAME COMP VAL
3393 or VAL COMP NAME. */
3395 {
3396 /* If the predicate is of the form VAL COMP NAME, flip
3397 COMP around because we need to register NAME as the
3398 first operand in the predicate. */
3401 }
3402 else
3403 {
3404 /* The comparison is of the form NAME COMP VAL, so the
3405 comparison code remains unchanged. */
3408 }
3410 /* If we are inserting the assertion on the ELSE edge, we
3411 need to invert the sign comparison. */
3415 /* Do not register always-false predicates. FIXME, this
3416 works around a limitation in fold() when dealing with
3417 enumerations. Given 'enum { N1, N2 } x;', fold will not
3418 fold 'if (x > N2)' to 'if (0)'. */
3422 {
3431 }
3432 }
3433 }
3434 else
3435 {
3436 /* FIXME. Handle SWITCH_EXPR. */
3438 }
3442 }
3447 /* Determine whether the outgoing edges of BB should receive an
3448 ASSERT_EXPR for each of the operands of BB's last statement. The
3449 last statement of BB must be a COND_EXPR or a SWITCH_EXPR.
3451 If any of the sub-graphs rooted at BB have an interesting use of
3452 the predicate operands, an assert location node is added to the
3453 list of assertions for the corresponding operands. */
3455 static bool
3457 {
3459 block_stmt_iterator last_si;
3461 edge_iterator ei;
3462 edge e;
3463 ssa_op_iter iter;
3469 /* Look for uses of the operands in each of the sub-graphs
3470 rooted at BB. We need to check each of the outgoing edges
3471 separately, so that we know what kind of ASSERT_EXPR to
3472 insert. */
3474 {
3478 /* Remove the COND_EXPR operands from the FOUND_IN_SUBGRAPH bitmap.
3479 Otherwise, when we finish traversing each of the sub-graphs, we
3480 won't know whether the variables were found in the sub-graphs or
3481 if they had been found in a block upstream from BB.
3483 This is actually a bad idea is some cases, particularly jump
3484 threading. Consider a CFG like the following:
3486 0
3487 /|
3488 1 |
3489 \|
3490 2
3491 / \
3492 3 4
3494 Assume that one or more operands in the conditional at the
3495 end of block 0 are used in a conditional in block 2, but not
3496 anywhere in block 1. In this case we will not insert any
3497 assert statements in block 1, which may cause us to miss
3498 opportunities to optimize, particularly for jump threading. */
3502 /* Traverse the strictly dominated sub-graph rooted at E->DEST
3503 to determine if any of the operands in the conditional
3504 predicate are used. */
3508 /* Register the necessary assertions for each operand in the
3509 conditional predicate. */
3512 }
3514 /* Finally, indicate that we have found the operands in the
3515 conditional. */
3520 }
3523 /* Traverse all the statements in block BB looking for statements that
3524 may generate useful assertions for the SSA names in their operand.
3525 If a statement produces a useful assertion A for name N_i, then the
3526 list of assertions already generated for N_i is scanned to
3527 determine if A is actually needed.
3529 If N_i already had the assertion A at a location dominating the
3530 current location, then nothing needs to be done. Otherwise, the
3531 new location for A is recorded instead.
3533 1- For every statement S in BB, all the variables used by S are
3534 added to bitmap FOUND_IN_SUBGRAPH.
3536 2- If statement S uses an operand N in a way that exposes a known
3537 value range for N, then if N was not already generated by an
3538 ASSERT_EXPR, create a new assert location for N. For instance,
3539 if N is a pointer and the statement dereferences it, we can
3540 assume that N is not NULL.
3542 3- COND_EXPRs are a special case of #2. We can derive range
3543 information from the predicate but need to insert different
3544 ASSERT_EXPRs for each of the sub-graphs rooted at the
3545 conditional block. If the last statement of BB is a conditional
3546 expression of the form 'X op Y', then
3548 a) Remove X and Y from the set FOUND_IN_SUBGRAPH.
3550 b) If the conditional is the only entry point to the sub-graph
3551 corresponding to the THEN_CLAUSE, recurse into it. On
3552 return, if X and/or Y are marked in FOUND_IN_SUBGRAPH, then
3553 an ASSERT_EXPR is added for the corresponding variable.
3555 c) Repeat step (b) on the ELSE_CLAUSE.
3557 d) Mark X and Y in FOUND_IN_SUBGRAPH.
3559 For instance,
3561 if (a == 9)
3562 b = a;
3563 else
3564 b = c + 1;
3566 In this case, an assertion on the THEN clause is useful to
3567 determine that 'a' is always 9 on that edge. However, an assertion
3568 on the ELSE clause would be unnecessary.
3570 4- If BB does not end in a conditional expression, then we recurse
3571 into BB's dominator children.
3573 At the end of the recursive traversal, every SSA name will have a
3574 list of locations where ASSERT_EXPRs should be added. When a new
3575 location for name N is found, it is registered by calling
3576 register_new_assert_for. That function keeps track of all the
3577 registered assertions to prevent adding unnecessary assertions.
3578 For instance, if a pointer P_4 is dereferenced more than once in a
3579 dominator tree, only the location dominating all the dereference of
3580 P_4 will receive an ASSERT_EXPR.
3582 If this function returns true, then it means that there are names
3583 for which we need to generate ASSERT_EXPRs. Those assertions are
3584 inserted by process_assert_insertions.
3586 TODO. Handle SWITCH_EXPR. */
3588 static bool
3590 {
3591 block_stmt_iterator si;
3594 basic_block son;
3603 /* Traverse all PHI nodes in BB marking used operands. */
3605 {
3606 use_operand_p arg_p;
3607 ssa_op_iter i;
3610 {
3613 {
3616 }
3617 }
3618 }
3620 /* Traverse all the statements in BB marking used names and looking
3621 for statements that may infer assertions for their used operands. */
3624 {
3626 ssa_op_iter i;
3630 /* See if we can derive an assertion for any of STMT's operands. */
3632 {
3633 tree value;
3636 /* Mark OP in bitmap FOUND_IN_SUBGRAPH. If STMT is inside
3637 the sub-graph of a conditional block, when we return from
3638 this recursive walk, our parent will use the
3639 FOUND_IN_SUBGRAPH bitset to determine if one of the
3640 operands it was looking for was present in the sub-graph. */
3643 /* If OP is used in such a way that we can infer a value
3644 range for it, and we don't find a previous assertion for
3645 it, create a new assertion location node for OP. */
3647 {
3648 /* If we are able to infer a nonzero value range for OP,
3649 then walk backwards through the use-def chain to see if OP
3650 was set via a typecast.
3652 If so, then we can also infer a nonzero value range
3653 for the operand of the NOP_EXPR. */
3655 {
3663 {
3667 /* Note we want to register the assert for the
3668 operand of the NOP_EXPR after SI, not after the
3669 conversion. */
3671 {
3675 }
3676 }
3677 }
3679 /* If OP is used only once, namely in this STMT, don't
3680 bother creating an ASSERT_EXPR for it. Such an
3681 ASSERT_EXPR would do nothing but increase compile time. */
3683 {
3686 }
3687 }
3688 }
3690 /* Remember the last statement of the block. */
3692 }
3694 /* If BB's last statement is a conditional expression
3695 involving integer operands, recurse into each of the sub-graphs
3696 rooted at BB to determine if we need to add ASSERT_EXPRs. */
3703 /* Recurse into the dominator children of BB. */
3705 son;
3710 }
3713 /* Create an ASSERT_EXPR for NAME and insert it in the location
3714 indicated by LOC. Return true if we made any edge insertions. */
3716 static bool
3718 {
3719 /* Build the comparison expression NAME_i COMP_CODE VAL. */
3721 edge_iterator ei;
3722 edge e;
3728 {
3729 /* We have been asked to insert the assertion on an edge. This
3730 is used only by COND_EXPR and SWITCH_EXPR assertions. */
3731 #if defined ENABLE_CHECKING
3734 #endif
3738 }
3740 /* Otherwise, we can insert right after LOC->SI iff the
3741 statement must not be the last statement in the block. */
3744 {
3747 }
3749 /* If STMT must be the last statement in BB, we can only insert new
3750 assertions on the non-abnormal edge out of BB. Note that since
3751 STMT is not control flow, there may only be one non-abnormal edge
3752 out of BB. */
3755 {
3758 }
3761 }
3764 /* Process all the insertions registered for every name N_i registered
3765 in NEED_ASSERT_FOR. The list of assertions to be inserted are
3766 found in ASSERTS_FOR[i]. */
3768 static void
3770 {
3772 bitmap_iterator bi;
3780 {
3785 {
3790 num_asserts++;
3791 }
3792 }
3799 num_asserts);
3800 }
3803 /* Traverse the flowgraph looking for conditional jumps to insert range
3804 expressions. These range expressions are meant to provide information
3805 to optimizations that need to reason in terms of value ranges. They
3806 will not be expanded into RTL. For instance, given:
3808 x = ...
3809 y = ...
3810 if (x < y)
3811 y = x - 2;
3812 else
3813 x = y + 3;
3815 this pass will transform the code into:
3817 x = ...
3818 y = ...
3819 if (x < y)
3820 {
3821 x = ASSERT_EXPR <x, x < y>
3822 y = x - 2
3823 }
3824 else
3825 {
3826 y = ASSERT_EXPR <y, x <= y>
3827 x = y + 3
3828 }
3830 The idea is that once copy and constant propagation have run, other
3831 optimizations will be able to determine what ranges of values can 'x'
3832 take in different paths of the code, simply by checking the reaching
3833 definition of 'x'. */
3835 static void
3837 {
3838 edge e;
3839 edge_iterator ei;
3860 {
3863 }
3866 {
3869 }
3874 }
3877 /* Convert range assertion expressions into the implied copies and
3878 copy propagate away the copies. Doing the trivial copy propagation
3879 here avoids the need to run the full copy propagation pass after
3880 VRP.
3882 FIXME, this will eventually lead to copy propagation removing the
3883 names that had useful range information attached to them. For
3884 instance, if we had the assertion N_i = ASSERT_EXPR <N_j, N_j > 3>,
3885 then N_i will have the range [3, +INF].
3887 However, by converting the assertion into the implied copy
3888 operation N_i = N_j, we will then copy-propagate N_j into the uses
3889 of N_i and lose the range information. We may want to hold on to
3890 ASSERT_EXPRs a little while longer as the ranges could be used in
3891 things like jump threading.
3893 The problem with keeping ASSERT_EXPRs around is that passes after
3894 VRP need to handle them appropriately.
3896 Another approach would be to make the range information a first
3897 class property of the SSA_NAME so that it can be queried from
3898 any pass. This is made somewhat more complex by the need for
3899 multiple ranges to be associated with one SSA_NAME. */
3901 static void
3903 {
3904 basic_block bb;
3905 block_stmt_iterator si;
3907 /* Note that the BSI iterator bump happens at the bottom of the
3908 loop and no bump is necessary if we're removing the statement
3909 referenced by the current BSI. */
3912 {
3914 tree use_stmt;
3918 {
3921 use_operand_p use_p;
3922 imm_use_iterator iter;
3926 /* Propagate the RHS into every use of the LHS. */
3930 {
3933 }
3935 /* And finally, remove the copy, it is not needed. */
3937 }
3938 else
3940 }
3943 }
3946 /* Return true if STMT is interesting for VRP. */
3948 static bool
3950 {
3957 {
3961 /* In general, assignments with virtual operands are not useful
3962 for deriving ranges, with the obvious exception of calls to
3963 builtin functions. */
3973 }
3978 }
3981 /* Initialize local data structures for VRP. */
3983 static void
3985 {
3986 basic_block bb;
3992 {
3993 block_stmt_iterator si;
3994 tree phi;
3997 {
3999 {
4003 }
4004 else
4006 }
4009 {
4013 {
4014 ssa_op_iter i;
4015 tree def;
4019 }
4020 else
4021 {
4023 }
4024 }
4025 }
4026 }
4029 /* Visit assignment STMT. If it produces an interesting range, record
4030 the SSA name in *OUTPUT_P. */
4032 static enum ssa_prop_result
4034 {
4036 ssa_op_iter iter;
4041 /* We only keep track of ranges in integral and pointer types. */
4044 /* It is valid to have NULL MIN/MAX values on a type. See
4045 build_range_type. */
4049 {
4055 /* If STMT is inside a loop, we may be able to know something
4056 else about the range of LHS by examining scalar evolution
4057 information. */
4062 {
4066 {
4072 }
4078 }
4081 }
4083 /* Every other statement produces no useful ranges. */
4088 }
4091 /* Compare all the value ranges for names equivalent to VAR with VAL
4092 using comparison code COMP. Return the same value returned by
4093 compare_range_with_value, including the setting of
4094 *STRICT_OVERFLOW_P. */
4096 static tree
4099 {
4100 bitmap_iterator bi;
4102 bitmap e;
4108 /* Get the set of equivalences for VAR. */
4111 /* Add VAR to its own set of equivalences so that VAR's value range
4112 is processed by this loop (otherwise, we would have to replicate
4113 the body of the loop just to check VAR's value range). */
4116 /* Start at -1. Set it to 0 if we do a comparison without relying
4117 on overflow, or 1 if all comparisons rely on overflow. */
4121 {
4126 /* If name N_i does not have a valid range, use N_i as its own
4127 range. This allows us to compare against names that may
4128 have N_i in their ranges. */
4130 {
4134 }
4139 {
4140 /* If we get different answers from different members
4141 of the equivalence set this check must be in a dead
4142 code region. Folding it to a trap representation
4143 would be correct here. For now just return don't-know. */
4146 {
4149 }
4156 }
4157 }
4159 /* Remove VAR from its own equivalence set. */
4163 {
4167 }
4169 /* We couldn't find a non-NULL value for the predicate. */
4171 }
4174 /* Given a comparison code COMP and names N1 and N2, compare all the
4175 ranges equivalent to N1 against all the ranges equivalent to N2
4176 to determine the value of N1 COMP N2. Return the same value
4177 returned by compare_ranges. Set *STRICT_OVERFLOW_P to indicate
4178 whether we relied on an overflow infinity in the comparison. */
4181 static tree
4184 {
4191 /* Compare the ranges of every name equivalent to N1 against the
4192 ranges of every name equivalent to N2. */
4196 /* Add N1 and N2 to their own set of equivalences to avoid
4197 duplicating the body of the loop just to check N1 and N2
4198 ranges. */
4202 /* If the equivalence sets have a common intersection, then the two
4203 names can be compared without checking their ranges. */
4205 {
4210 ? boolean_true_node
4212 }
4214 /* Start at -1. Set it to 0 if we do a comparison without relying
4215 on overflow, or 1 if all comparisons rely on overflow. */
4218 /* Otherwise, compare all the equivalent ranges. First, add N1 and
4219 N2 to their own set of equivalences to avoid duplicating the body
4220 of the loop just to check N1 and N2 ranges. */
4222 {
4225 /* If the range is VARYING or UNDEFINED, use the name itself. */
4227 {
4231 }
4235 {
4241 {
4245 }
4249 {
4250 /* If we get different answers from different members
4251 of the equivalence set this check must be in a dead
4252 code region. Folding it to a trap representation
4253 would be correct here. For now just return don't-know. */
4256 {
4260 }
4267 }
4268 }
4271 {
4277 }
4278 }
4280 /* None of the equivalent ranges are useful in computing this
4281 comparison. */
4285 }
4288 /* Given a conditional predicate COND, try to determine if COND yields
4289 true or false based on the value ranges of its operands. Return
4290 BOOLEAN_TRUE_NODE if the conditional always evaluates to true,
4291 BOOLEAN_FALSE_NODE if the conditional always evaluates to false, and,
4292 NULL if the conditional cannot be evaluated at compile time.
4294 If USE_EQUIV_P is true, the ranges of all the names equivalent with
4295 the operands in COND are used when trying to compute its value.
4296 This is only used during final substitution. During propagation,
4297 we only check the range of each variable and not its equivalents.
4299 Set *STRICT_OVERFLOW_P to indicate whether we relied on an overflow
4300 infinity to produce the result. */
4302 static tree
4305 {
4310 {
4312 tree retval;
4316 strict_overflow_p);
4317 else
4318 {
4321 strict_overflow_p);
4322 }
4324 /* If COND has a known boolean range, return it. */
4328 /* Otherwise, if COND has a symbolic range of exactly one value,
4329 return it. */
4333 }
4334 else
4335 {
4339 /* We only deal with integral and pointer types. */
4345 {
4348 strict_overflow_p);
4351 strict_overflow_p);
4355 strict_overflow_p));
4356 }
4357 else
4358 {
4366 strict_overflow_p);
4369 strict_overflow_p);
4373 strict_overflow_p));
4374 }
4375 }
4377 /* Anything else cannot be computed statically. */
4379 }
4381 /* Given COND within STMT, try to simplify it based on value range
4382 information. Return NULL if the conditional can not be evaluated.
4383 The ranges of all the names equivalent with the operands in COND
4384 will be used when trying to compute the value. If the result is
4385 based on undefined signed overflow, issue a warning if
4386 appropriate. */
4388 tree
4390 {
4392 tree ret;
4398 {
4403 {
4407 }
4408 else
4409 {
4413 }
4416 {
4417 location_t locus;
4421 else
4424 }
4425 }
4428 }
4431 /* Visit conditional statement STMT. If we can determine which edge
4432 will be taken out of STMT's basic block, record it in
4433 *TAKEN_EDGE_P and return SSA_PROP_INTERESTING. Otherwise, return
4434 SSA_PROP_VARYING. */
4436 static enum ssa_prop_result
4438 {
4444 /* FIXME. Handle SWITCH_EXPRs. But first, the assert pass needs to
4445 add ASSERT_EXPRs for them. */
4452 {
4453 tree use;
4454 ssa_op_iter i;
4461 {
4466 }
4469 }
4471 /* Compute the value of the predicate COND by checking the known
4472 ranges of each of its operands.
4474 Note that we cannot evaluate all the equivalent ranges here
4475 because those ranges may not yet be final and with the current
4476 propagation strategy, we cannot determine when the value ranges
4477 of the names in the equivalence set have changed.
4479 For instance, given the following code fragment
4481 i_5 = PHI <8, i_13>
4482 ...
4483 i_14 = ASSERT_EXPR <i_5, i_5 != 0>
4484 if (i_14 == 1)
4485 ...
4487 Assume that on the first visit to i_14, i_5 has the temporary
4488 range [8, 8] because the second argument to the PHI function is
4489 not yet executable. We derive the range ~[0, 0] for i_14 and the
4490 equivalence set { i_5 }. So, when we visit 'if (i_14 == 1)' for
4491 the first time, since i_14 is equivalent to the range [8, 8], we
4492 determine that the predicate is always false.
4494 On the next round of propagation, i_13 is determined to be
4495 VARYING, which causes i_5 to drop down to VARYING. So, another
4496 visit to i_14 is scheduled. In this second visit, we compute the
4497 exact same range and equivalence set for i_14, namely ~[0, 0] and
4498 { i_5 }. But we did not have the previous range for i_5
4499 registered, so vrp_visit_assignment thinks that the range for
4500 i_14 has not changed. Therefore, the predicate 'if (i_14 == 1)'
4501 is not visited again, which stops propagation from visiting
4502 statements in the THEN clause of that if().
4504 To properly fix this we would need to keep the previous range
4505 value for the names in the equivalence set. This way we would've
4506 discovered that from one visit to the other i_5 changed from
4507 range [8, 8] to VR_VARYING.
4509 However, fixing this apparent limitation may not be worth the
4510 additional checking. Testing on several code bases (GCC, DLV,
4511 MICO, TRAMP3D and SPEC2000) showed that doing this results in
4512 4 more predicates folded in SPEC. */
4516 {
4519 else
4520 {
4526 }
4527 }
4530 {
4534 else
4536 }
4539 }
4542 /* Evaluate statement STMT. If the statement produces a useful range,
4543 return SSA_PROP_INTERESTING and record the SSA name with the
4544 interesting range into *OUTPUT_P.
4546 If STMT is a conditional branch and we can determine its truth
4547 value, the taken edge is recorded in *TAKEN_EDGE_P.
4549 If STMT produces a varying value, return SSA_PROP_VARYING. */
4551 static enum ssa_prop_result
4553 {
4554 tree def;
4555 ssa_op_iter iter;
4556 stmt_ann_t ann;
4559 {
4563 }
4567 {
4570 /* In general, assignments with virtual operands are not useful
4571 for deriving ranges, with the obvious exception of calls to
4572 builtin functions. */
4579 }
4583 /* All other statements produce nothing of interest for VRP, so mark
4584 their outputs varying and prevent further simulation. */
4589 }
4592 /* Meet operation for value ranges. Given two value ranges VR0 and
4593 VR1, store in VR0 the result of meeting VR0 and VR1.
4595 The meeting rules are as follows:
4597 1- If VR0 and VR1 have an empty intersection, set VR0 to VR_VARYING.
4599 2- If VR0 and VR1 have a non-empty intersection, set VR0 to the
4600 union of VR0 and VR1. */
4602 static void
4604 {
4606 {
4609 }
4612 {
4613 /* Nothing to do. VR0 already has the resulting range. */
4615 }
4618 {
4619 /* Nothing to do. VR0 already has the resulting range. */
4621 }
4624 {
4627 }
4630 {
4631 /* If VR0 and VR1 have a non-empty intersection, compute the
4632 union of both ranges. */
4634 {
4638 /* The lower limit of the new range is the minimum of the
4639 two ranges. If they cannot be compared, the result is
4640 VARYING. */
4646 else
4647 {
4650 }
4652 /* Similarly, the upper limit of the new range is the
4653 maximum of the two ranges. If they cannot be compared,
4654 the result is VARYING. */
4660 else
4661 {
4664 }
4666 /* Check for useless ranges. */
4670 {
4673 }
4675 /* The resulting set of equivalences is the intersection of
4676 the two sets. */
4683 }
4684 else
4686 }
4688 {
4689 /* Two anti-ranges meet only if they are both identical. */
4693 {
4694 /* The resulting set of equivalences is the intersection of
4695 the two sets. */
4700 }
4701 else
4703 }
4705 {
4706 /* A numeric range [VAL1, VAL2] and an anti-range ~[VAL3, VAL4]
4707 meet only if the ranges have an empty intersection. The
4708 result of the meet operation is the anti-range. */
4712 {
4713 /* Copy most of VR1 into VR0. Don't copy VR1's equivalence
4714 set. We need to compute the intersection of the two
4715 equivalence sets. */
4719 /* The resulting set of equivalences is the intersection of
4720 the two sets. */
4725 }
4726 else
4728 }
4729 else
4734 no_meet:
4735 /* The two range VR0 and VR1 do not meet. Before giving up and
4736 setting the result to VARYING, see if we can at least derive a
4737 useful anti-range. FIXME, all this nonsense about distinguishing
4738 anti-ranges from ranges is necessary because of the odd
4739 semantics of range_includes_zero_p and friends. */
4746 {
4749 /* Since this meet operation did not result from the meeting of
4750 two equivalent names, VR0 cannot have any equivalences. */
4753 }
4754 else
4756 }
4759 /* Visit all arguments for PHI node PHI that flow through executable
4760 edges. If a valid value range can be derived from all the incoming
4761 value ranges, set a new range for the LHS of PHI. */
4763 static enum ssa_prop_result
4765 {
4774 {
4777 }
4780 {
4784 {
4789 }
4792 {
4794 value_range_t vr_arg;
4798 else
4799 {
4801 {
4804 }
4810 }
4813 {
4819 }
4825 }
4826 }
4831 /* To prevent infinite iterations in the algorithm, derive ranges
4832 when the new value is slightly bigger or smaller than the
4833 previous one. */
4835 {
4837 {
4841 /* If the new minimum is smaller or larger than the previous
4842 one, go all the way to -INF. In the first case, to avoid
4843 iterating millions of times to reach -INF, and in the
4844 other case to avoid infinite bouncing between different
4845 minimums. */
4847 {
4848 /* If we will end up with a (-INF, +INF) range, set it
4849 to VARYING. */
4859 else
4861 }
4863 /* Similarly, if the new maximum is smaller or larger than
4864 the previous one, go all the way to +INF. */
4866 {
4867 /* If we will end up with a (-INF, +INF) range, set it
4868 to VARYING. */
4878 else
4880 }
4881 }
4882 }
4884 /* If the new range is different than the previous value, keep
4885 iterating. */
4889 /* Nothing changed, don't add outgoing edges. */
4892 /* No match found. Set the LHS to VARYING. */
4893 varying:
4896 }
4898 /* Simplify a division or modulo operator to a right shift or
4899 bitwise and if the first operand is unsigned or is greater
4900 than zero and the second operand is an exact power of two. */
4902 static void
4904 {
4910 {
4912 }
4913 else
4914 {
4920 && sop
4923 {
4924 location_t locus;
4928 else
4934 }
4935 }
4938 {
4939 tree t;
4944 {
4947 }
4948 else
4949 {
4954 }
4958 }
4959 }
4961 /* If the operand to an ABS_EXPR is >= 0, then eliminate the
4962 ABS_EXPR. If the operand is <= 0, then simplify the
4963 ABS_EXPR into a NEGATE_EXPR. */
4965 static void
4967 {
4974 {
4976 }
4978 {
4983 {
4989 {
4994 }
4995 }
4999 {
5000 tree t;
5003 {
5004 location_t locus;
5008 else
5014 }
5018 else
5023 }
5024 }
5025 }
5027 /* We are comparing trees OP0 and OP1 using COND_CODE. OP0 has
5028 a known value range VR.
5030 If there is one and only one value which will satisfy the
5031 conditional, then return that value. Else return NULL. */
5033 static tree
5036 {
5040 /* Extract minimum/maximum values which satisfy the
5041 the conditional as it was written. */
5043 {
5044 /* This should not be negative infinity; there is no overflow
5045 here. */
5050 {
5055 }
5056 }
5058 {
5059 /* This should not be positive infinity; there is no overflow
5060 here. */
5065 {
5070 }
5071 }
5073 /* Now refine the minimum and maximum values using any
5074 value range information we have for op0. */
5076 {
5079 else
5083 else
5086 /* If the new min/max values have converged to a single value,
5087 then there is only one value which can satisfy the condition,
5088 return that value. */
5091 }
5093 }
5095 /* Simplify a conditional using a relational operator to an equality
5096 test if the range information indicates only one value can satisfy
5097 the original conditional. */
5099 static void
5101 {
5112 {
5115 /* If we have range information for OP0, then we might be
5116 able to simplify this conditional. */
5118 {
5122 {
5124 {
5128 }
5135 {
5138 }
5141 }
5143 /* Try again after inverting the condition. We only deal
5144 with integral types here, so no need to worry about
5145 issues with inverting FP comparisons. */
5150 {
5152 {
5156 }
5163 {
5166 }
5169 }
5170 }
5171 }
5172 }
5174 /* Simplify STMT using ranges if possible. */
5176 void
5178 {
5180 {
5184 /* Transform TRUNC_DIV_EXPR and TRUNC_MOD_EXPR into RSHIFT_EXPR
5185 and BIT_AND_EXPR respectively if the first operand is greater
5186 than zero and the second operand is an exact power of two. */
5192 /* Transform ABS (X) into X or -X as appropriate. */
5197 }
5200 {
5202 }
5203 }
5205 /* Stack of dest,src equivalency pairs that need to be restored after
5206 each attempt to thread a block's incoming edge to an outgoing edge.
5208 A NULL entry is used to mark the end of pairs which need to be
5209 restored. */
5212 /* A trivial wrapper so that we can present the generic jump threading
5213 code with a simple API for simplifying statements. STMT is the
5214 statement we want to simplify, WITHIN_STMT provides the location
5215 for any overflow warnings. */
5217 static tree
5219 {
5220 /* We only use VRP information to simplify conditionals. This is
5221 overly conservative, but it's unclear if doing more would be
5222 worth the compile time cost. */
5227 }
5229 /* Blocks which have more than one predecessor and more than
5230 one successor present jump threading opportunities. ie,
5231 when the block is reached from a specific predecessor, we
5232 may be able to determine which of the outgoing edges will
5233 be traversed. When this optimization applies, we are able
5234 to avoid conditionals at runtime and we may expose secondary
5235 optimization opportunities.
5237 This routine is effectively a driver for the generic jump
5238 threading code. It basically just presents the generic code
5239 with edges that may be suitable for jump threading.
5241 Unlike DOM, we do not iterate VRP if jump threading was successful.
5242 While iterating may expose new opportunities for VRP, it is expected
5243 those opportunities would be very limited and the compile time cost
5244 to expose those opportunities would be significant.
5246 As jump threading opportunities are discovered, they are registered
5247 for later realization. */
5249 static void
5251 {
5252 basic_block bb;
5253 tree dummy;
5255 /* Ugh. When substituting values earlier in this pass we can
5256 wipe the dominance information. So rebuild the dominator
5257 information as we need it within the jump threading code. */
5260 /* We do not allow VRP information to be used for jump threading
5261 across a back edge in the CFG. Otherwise it becomes too
5262 difficult to avoid eliminating loop exit tests. Of course
5263 EDGE_DFS_BACK is not accurate at this time so we have to
5264 recompute it. */
5267 /* Allocate our unwinder stack to unwind any temporary equivalences
5268 that might be recorded. */
5271 /* To avoid lots of silly node creation, we create a single
5272 conditional and just modify it in-place when attempting to
5273 thread jumps. */
5277 /* Walk through all the blocks finding those which present a
5278 potential jump threading opportunity. We could set this up
5279 as a dominator walker and record data during the walk, but
5280 I doubt it's worth the effort for the classes of jump
5281 threading opportunities we are trying to identify at this
5282 point in compilation. */
5284 {
5287 /* If the generic jump threading code does not find this block
5288 interesting, then there is nothing to do. */
5292 /* We only care about blocks ending in a COND_EXPR. While there
5293 may be some value in handling SWITCH_EXPR here, I doubt it's
5294 terribly important. */
5299 /* We're basically looking for any kind of conditional with
5300 integral type arguments. */
5310 {
5311 edge_iterator ei;
5312 edge e;
5314 /* We've got a block with multiple predecessors and multiple
5315 successors which also ends in a suitable conditional. For
5316 each predecessor, see if we can thread it to a specific
5317 successor. */
5319 {
5320 /* Do not thread across back edges or abnormal edges
5321 in the CFG. */
5327 simplify_stmt_for_jump_threading);
5328 }
5329 }
5330 }
5332 /* We do not actually update the CFG or SSA graphs at this point as
5333 ASSERT_EXPRs are still in the IL and cfg cleanup code does not yet
5334 handle ASSERT_EXPRs gracefully. */
5335 }
5337 /* We identified all the jump threading opportunities earlier, but could
5338 not transform the CFG at that time. This routine transforms the
5339 CFG and arranges for the dominator tree to be rebuilt if necessary.
5341 Note the SSA graph update will occur during the normal TODO
5342 processing by the pass manager. */
5343 static void
5345 {
5349 /* If we threaded jumps, then we need to recompute the dominance
5350 information, to safely do that we must clean up the CFG first. */
5352 {
5356 }
5358 }
5361 /* Traverse all the blocks folding conditionals with known ranges. */
5363 static void
5365 {
5371 {
5375 }
5377 /* We may have ended with ranges that have exactly one value. Those
5378 values can be substituted as any other copy/const propagated
5379 value using substitute_and_fold. */
5388 {
5391 }
5394 {
5395 /* We found no single-valued ranges, don't waste time trying to
5396 do single value substitution in substitute_and_fold. */
5399 }
5403 /* We must identify jump threading opportunities before we release
5404 the datastructures built by VRP. */
5407 /* Free allocated memory. */
5410 {
5413 }
5418 /* So that we can distinguish between VRP data being available
5419 and not available. */
5421 }
5424 /* Main entry point to VRP (Value Range Propagation). This pass is
5425 loosely based on J. R. C. Patterson, ``Accurate Static Branch
5426 Prediction by Value Range Propagation,'' in SIGPLAN Conference on
5427 Programming Language Design and Implementation, pp. 67-78, 1995.
5428 Also available at http://citeseer.ist.psu.edu/patterson95accurate.html
5430 This is essentially an SSA-CCP pass modified to deal with ranges
5431 instead of constants.
5433 While propagating ranges, we may find that two or more SSA name
5434 have equivalent, though distinct ranges. For instance,
5436 1 x_9 = p_3->a;
5437 2 p_4 = ASSERT_EXPR <p_3, p_3 != 0>
5438 3 if (p_4 == q_2)
5439 4 p_5 = ASSERT_EXPR <p_4, p_4 == q_2>;
5440 5 endif
5441 6 if (q_2)
5443 In the code above, pointer p_5 has range [q_2, q_2], but from the
5444 code we can also determine that p_5 cannot be NULL and, if q_2 had
5445 a non-varying range, p_5's range should also be compatible with it.
5447 These equivalences are created by two expressions: ASSERT_EXPR and
5448 copy operations. Since p_5 is an assertion on p_4, and p_4 was the
5449 result of another assertion, then we can use the fact that p_5 and
5450 p_4 are equivalent when evaluating p_5's range.
5452 Together with value ranges, we also propagate these equivalences
5453 between names so that we can take advantage of information from
5454 multiple ranges when doing final replacement. Note that this
5455 equivalency relation is transitive but not symmetric.
5457 In the example above, p_5 is equivalent to p_4, q_2 and p_3, but we
5458 cannot assert that q_2 is equivalent to p_5 because q_2 may be used
5459 in contexts where that assertion does not hold (e.g., in line 6).
5461 TODO, the main difference between this pass and Patterson's is that
5462 we do not propagate edge probabilities. We only compute whether
5463 edges can be taken or not. That is, instead of having a spectrum
5464 of jump probabilities between 0 and 1, we only deal with 0, 1 and
5465 DON'T KNOW. In the future, it may be worthwhile to propagate
5466 probabilities to aid branch prediction. */
5468 static unsigned int
5470 {
5482 {
5486 }
5488 /* ASSERT_EXPRs must be removed before finalizing jump threads
5489 as finalizing jump threads calls the CFG cleanup code which
5490 does not properly handle ASSERT_EXPRs. */
5493 /* If we exposed any new variables, go ahead and put them into
5494 SSA form now, before we handle jump threading. This simplifies
5495 interactions between rewriting of _DECL nodes into SSA form
5496 and rewriting SSA_NAME nodes into SSA form after block
5497 duplication and CFG manipulation. */
5502 }
5504 static bool
5506 {
5508 }
5511 {
5523 TODO_cleanup_cfg
5524 | TODO_ggc_collect
5525 | TODO_verify_ssa
5526 | TODO_dump_func
5527 | TODO_update_ssa
5530 };