| blob | 2babe1a25b7cdaee2e6450cecd24977477c0a354 |
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. */
41 /* Set of SSA names found during the dominator traversal of a
42 sub-graph in find_assert_locations. */
45 /* Local functions. */
49 /* Location information for ASSERT_EXPRs. Each instance of this
50 structure describes an ASSERT_EXPR for an SSA name. Since a single
51 SSA name may have more than one assertion associated with it, these
52 locations are kept in a linked list attached to the corresponding
53 SSA name. */
54 struct assert_locus_d
55 {
56 /* Basic block where the assertion would be inserted. */
57 basic_block bb;
59 /* Some assertions need to be inserted on an edge (e.g., assertions
60 generated by COND_EXPRs). In those cases, BB will be NULL. */
61 edge e;
63 /* Pointer to the statement that generated this assertion. */
64 block_stmt_iterator si;
66 /* Predicate code for the ASSERT_EXPR. Must be COMPARISON_CLASS_P. */
69 /* Value being compared against. */
70 tree val;
72 /* Next node in the linked list. */
74 };
78 /* If bit I is present, it means that SSA name N_i has a list of
79 assertions that should be inserted in the IL. */
82 /* Array of locations lists where to insert assertions. ASSERTS_FOR[I]
83 holds a list of ASSERT_LOCUS_T nodes that describe where
84 ASSERT_EXPRs for SSA name N_I should be inserted. */
87 /* Set of blocks visited in find_assert_locations. Used to avoid
88 visiting the same block more than once. */
91 /* Value range array. After propagation, VR_VALUE[I] holds the range
92 of values that SSA name N_I may take. */
96 /* Return true if ARG is marked with the nonnull attribute in the
97 current function signature. */
99 static bool
101 {
107 /* The static chain decl is always non null. */
114 /* If "nonnull" wasn't specified, we know nothing about the argument. */
118 /* If "nonnull" applies to all the arguments, then ARG is non-null. */
122 /* Get the position number for ARG in the function signature. */
124 t;
126 {
129 }
133 /* Now see if ARG_NUM is mentioned in the nonnull list. */
135 {
138 }
141 }
144 /* Set value range VR to {T, MIN, MAX, EQUIV}. */
146 static void
149 {
150 #if defined ENABLE_CHECKING
151 /* Check the validity of the range. */
153 {
164 }
171 #endif
177 /* Since updating the equivalence set involves deep copying the
178 bitmaps, only do it if absolutely necessary. */
183 {
186 else
188 }
189 }
192 /* Copy value range FROM into value range TO. */
196 {
198 }
200 /* Set value range VR to a non-negative range of type TYPE. */
204 {
207 }
209 /* Set value range VR to a non-NULL range of type TYPE. */
213 {
216 }
219 /* Set value range VR to a NULL range of type TYPE. */
223 {
226 }
229 /* Set value range VR to VR_VARYING. */
233 {
238 }
241 /* Set value range VR to a range of a truthvalue of type TYPE. */
245 {
248 else
252 }
255 /* Set value range VR to VR_UNDEFINED. */
259 {
264 }
267 /* Return value range information for VAR.
269 If we have no values ranges recorded (ie, VRP is not running), then
270 return NULL. Otherwise create an empty range if none existed for VAR. */
274 {
276 tree sym;
279 /* If we have no recorded ranges, then return NULL. */
287 /* Create a default value range. */
290 /* Allocate an equivalence set. */
293 /* If VAR is a default definition, the variable can take any value
294 in VAR's type. */
297 {
298 /* Try to use the "nonnull" attribute to create ~[0, 0]
299 anti-ranges for pointers. Note that this is only valid with
300 default definitions of PARM_DECLs. */
305 else
307 }
310 }
312 /* Return true, if VAL1 and VAL2 are equal values for VRP purposes. */
316 {
320 }
322 /* Return true, if the bitmaps B1 and B2 are equal. */
326 {
330 }
332 /* Update the value range and equivalence set for variable VAR to
333 NEW_VR. Return true if NEW_VR is different from VAR's previous
334 value.
336 NOTE: This function assumes that NEW_VR is a temporary value range
337 object created for the sole purpose of updating VAR's range. The
338 storage used by the equivalence set from NEW_VR will be freed by
339 this function. Do not call update_value_range when NEW_VR
340 is the range object associated with another SSA name. */
344 {
348 /* Update the value range, if necessary. */
363 }
366 /* Add VAR and VAR's equivalence set to EQUIV. */
368 static void
370 {
377 }
380 /* Return true if VR is ~[0, 0]. */
384 {
388 }
391 /* Return true if VR is [0, 0]. */
395 {
399 }
402 /* Return true if value range VR involves at least one symbol. */
406 {
409 }
411 /* Like tree_expr_nonnegative_p, but this function uses value ranges
412 obtained so far. */
414 static bool
416 {
418 }
420 /* Like tree_expr_nonzero_p, but this function uses value ranges
421 obtained so far. */
423 static bool
425 {
429 /* If we have an expression of the form &X->a, then the expression
430 is nonnull if X is nonnull. */
432 {
438 {
442 }
443 }
446 }
448 /* Returns true if EXPR is a valid value (as expected by compare_values) --
449 a gimple invariant, or SSA_NAME +- CST. */
451 static bool
453 {
463 }
465 /* Return
466 1 if VAL < VAL2
467 0 if !(VAL < VAL2)
468 -2 if those are incomparable. */
471 {
472 tree tcmp;
473 /* LT is folded faster than GE and others. Inline the common case. */
475 {
478 else
480 }
481 else
486 }
488 /* Compare two values VAL1 and VAL2. Return
490 -2 if VAL1 and VAL2 cannot be compared at compile-time,
491 -1 if VAL1 < VAL2,
492 0 if VAL1 == VAL2,
493 +1 if VAL1 > VAL2, and
494 +2 if VAL1 != VAL2
496 This is similar to tree_int_cst_compare but supports pointer values
497 and values that cannot be compared at compile time. */
499 static int
501 {
505 /* Below we rely on the fact that VAL1 and VAL2 are both pointers or
506 both integers. */
516 {
520 /* If VAL1 and VAL2 are of the form 'NAME [+-] CST' or 'NAME',
521 return -1 or +1 accordingly. If VAL1 and VAL2 don't use the
522 same name, return -2. */
524 {
528 }
529 else
530 {
535 {
540 }
541 }
544 {
548 }
549 else
550 {
555 {
560 }
561 }
563 /* Both values must use the same name. */
569 /* NAME == NAME */
572 /* If overflow is defined we cannot simplify more. */
577 {
579 /* NAME < NAME + CST */
582 /* NAME > NAME - CST */
584 }
586 {
588 /* NAME + CST > NAME */
591 /* NAME + CST1 > NAME + CST2, if CST1 > CST2 */
594 /* NAME + CST1 > NAME - CST2 */
596 }
598 {
600 /* NAME - CST < NAME */
603 /* NAME - CST1 < NAME + CST2 */
606 /* NAME - CST1 > NAME - CST2, if CST1 < CST2. Notice that
607 C1 and C2 are swapped in the call to compare_values. */
609 }
612 }
614 /* We cannot compare non-constants. */
619 {
620 /* We cannot compare overflowed values. */
625 }
626 else
627 {
628 tree t;
630 /* First see if VAL1 and VAL2 are not the same. */
634 /* If VAL1 is a lower address than VAL2, return -1. */
638 /* If VAL1 is a higher address than VAL2, return +1. */
642 /* If VAL1 is different than VAL2, return +2.
643 For integer constants we either have already returned -1 or 1
644 or they are equivalent. We still might succeed in proving
645 something about non-trivial operands. */
648 {
652 }
655 }
656 }
659 /* Return 1 if VAL is inside value range VR (VR->MIN <= VAL <= VR->MAX),
660 0 if VAL is not inside VR,
661 -2 if we cannot tell either way.
663 FIXME, the current semantics of this functions are a bit quirky
664 when taken in the context of VRP. In here we do not care
665 about VR's type. If VR is the anti-range ~[3, 5] the call
666 value_inside_range (4, VR) will return 1.
668 This is counter-intuitive in a strict sense, but the callers
669 currently expect this. They are calling the function
670 merely to determine whether VR->MIN <= VAL <= VR->MAX. The
671 callers are applying the VR_RANGE/VR_ANTI_RANGE semantics
672 themselves.
674 This also applies to value_ranges_intersect_p and
675 range_includes_zero_p. The semantics of VR_RANGE and
676 VR_ANTI_RANGE should be encoded here, but that also means
677 adapting the users of these functions to the new semantics.
679 Benchmark compile/20001226-1.c compilation time after changing this
680 function. */
684 {
698 }
701 /* Return true if value ranges VR0 and VR1 have a non-empty
702 intersection.
704 Benchmark compile/20001226-1.c compilation time after changing this
705 function.
706 */
710 {
711 /* The value ranges do not intersect if the maximum of the first range is
712 less than the minimum of the second range or vice versa.
713 When those relations are unknown, we can't do any better. */
719 }
722 /* Return true if VR includes the value zero, false otherwise. FIXME,
723 currently this will return false for an anti-range like ~[-4, 3].
724 This will be wrong when the semantics of value_inside_range are
725 modified (currently the users of this function expect these
726 semantics). */
730 {
731 tree zero;
739 }
741 /* Return true if T, an SSA_NAME, is known to be nonnegative. Return
742 false otherwise or if no value range information is available. */
744 bool
746 {
752 /* Testing for VR_ANTI_RANGE is not useful here as any anti-range
753 which would return a useful value should be encoded as a VR_RANGE. */
755 {
759 }
761 }
763 /* Return true if T, an SSA_NAME, is known to be nonzero. Return
764 false otherwise or if no value range information is available. */
766 bool
768 {
774 /* A VR_RANGE which does not include zero is a nonzero value. */
778 /* A VR_ANTI_RANGE which does include zero is a nonzero value. */
783 }
786 /* Extract value range information from an ASSERT_EXPR EXPR and store
787 it in *VR_P. */
789 static void
791 {
801 /* Find VAR in the ASSERT_EXPR conditional. */
803 {
804 /* If the predicate is of the form VAR COMP LIMIT, then we just
805 take LIMIT from the RHS and use the same comparison code. */
808 }
809 else
810 {
811 /* If the predicate is of the form LIMIT COMP VAR, then we need
812 to flip around the comparison code to create the proper range
813 for VAR. */
816 }
821 /* For pointer arithmetic, we only keep track of pointer equality
822 and inequality. */
824 {
827 }
829 /* If LIMIT is another SSA name and LIMIT has a range of its own,
830 try to use LIMIT's range to avoid creating symbolic ranges
831 unnecessarily. */
834 /* LIMIT's range is only interesting if it has any useful information. */
841 /* Initially, the new range has the same set of equivalences of
842 VAR's range. This will be revised before returning the final
843 value. Since assertions may be chained via mutually exclusive
844 predicates, we will need to trim the set of equivalences before
845 we are done. */
850 /* Extract a new range based on the asserted comparison for VAR and
851 LIMIT's value range. Notice that if LIMIT has an anti-range, we
852 will only use it for equality comparisons (EQ_EXPR). For any
853 other kind of assertion, we cannot derive a range from LIMIT's
854 anti-range that can be used to describe the new range. For
855 instance, ASSERT_EXPR <x_2, x_2 <= b_4>. If b_4 is ~[2, 10],
856 then b_4 takes on the ranges [-INF, 1] and [11, +INF]. There is
857 no single range for x_2 that could describe LE_EXPR, so we might
858 as well build the range [b_4, +INF] for it. */
860 {
864 {
868 }
869 else
870 {
874 }
878 /* When asserting the equality VAR == LIMIT and LIMIT is another
879 SSA name, the new range will also inherit the equivalence set
880 from LIMIT. */
883 }
885 {
886 /* As described above, when LIMIT's range is an anti-range and
887 this assertion is an inequality (NE_EXPR), then we cannot
888 derive anything from the anti-range. For instance, if
889 LIMIT's range was ~[0, 0], the assertion 'VAR != LIMIT' does
890 not imply that VAR's range is [0, 0]. So, in the case of
891 anti-ranges, we just assert the inequality using LIMIT and
892 not its anti-range.
894 If LIMIT_VR is a range, we can only use it to build a new
895 anti-range if LIMIT_VR is a single-valued range. For
896 instance, if LIMIT_VR is [0, 1], the predicate
897 VAR != [0, 1] does not mean that VAR's range is ~[0, 1].
898 Rather, it means that for value 0 VAR should be ~[0, 0]
899 and for value 1, VAR should be ~[1, 1]. We cannot
900 represent these ranges.
902 The only situation in which we can build a valid
903 anti-range is when LIMIT_VR is a single-valued range
904 (i.e., LIMIT_VR->MIN == LIMIT_VR->MAX). In that case,
905 build the anti-range ~[LIMIT_VR->MIN, LIMIT_VR->MAX]. */
909 {
912 }
913 else
914 {
915 /* In any other case, we cannot use LIMIT's range to build a
916 valid anti-range. */
918 }
920 /* If MIN and MAX cover the whole range for their type, then
921 just use the original LIMIT. */
928 }
930 {
935 else
936 {
937 /* If LIMIT_VR is of the form [N1, N2], we need to build the
938 range [MIN, N2] for LE_EXPR and [MIN, N2 - 1] for
939 LT_EXPR. */
941 }
943 /* If the maximum value forces us to be out of bounds, simply punt.
944 It would be pointless to try and do anything more since this
945 all should be optimized away above us. */
948 else
949 {
950 /* For LT_EXPR, we create the range [MIN, MAX - 1]. */
952 {
955 }
958 }
959 }
961 {
966 else
967 {
968 /* If LIMIT_VR is of the form [N1, N2], we need to build the
969 range [N1, MAX] for GE_EXPR and [N1 + 1, MAX] for
970 GT_EXPR. */
972 }
974 /* If the minimum value forces us to be out of bounds, simply punt.
975 It would be pointless to try and do anything more since this
976 all should be optimized away above us. */
979 else
980 {
981 /* For GT_EXPR, we create the range [MIN + 1, MAX]. */
983 {
986 }
989 }
990 }
991 else
994 /* If VAR already had a known range, it may happen that the new
995 range we have computed and VAR's range are not compatible. For
996 instance,
998 if (p_5 == NULL)
999 p_6 = ASSERT_EXPR <p_5, p_5 == NULL>;
1000 x_7 = p_6->fld;
1001 p_8 = ASSERT_EXPR <p_6, p_6 != NULL>;
1003 While the above comes from a faulty program, it will cause an ICE
1004 later because p_8 and p_6 will have incompatible ranges and at
1005 the same time will be considered equivalent. A similar situation
1006 would arise from
1008 if (i_5 > 10)
1009 i_6 = ASSERT_EXPR <i_5, i_5 > 10>;
1010 if (i_5 < 5)
1011 i_7 = ASSERT_EXPR <i_6, i_6 < 5>;
1013 Again i_6 and i_7 will have incompatible ranges. It would be
1014 pointless to try and do anything with i_7's range because
1015 anything dominated by 'if (i_5 < 5)' will be optimized away.
1016 Note, due to the wa in which simulation proceeds, the statement
1017 i_7 = ASSERT_EXPR <...> we would never be visited because the
1018 conditional 'if (i_5 < 5)' always evaluates to false. However,
1019 this extra check does not hurt and may protect against future
1020 changes to VRP that may get into a situation similar to the
1021 NULL pointer dereference example.
1023 Note that these compatibility tests are only needed when dealing
1024 with ranges or a mix of range and anti-range. If VAR_VR and VR_P
1025 are both anti-ranges, they will always be compatible, because two
1026 anti-ranges will always have a non-empty intersection. */
1030 /* We may need to make adjustments when VR_P and VAR_VR are numeric
1031 ranges or anti-ranges. */
1041 {
1042 /* If the two ranges have a non-empty intersection, we can
1043 refine the resulting range. Since the assert expression
1044 creates an equivalency and at the same time it asserts a
1045 predicate, we can take the intersection of the two ranges to
1046 get better precision. */
1048 {
1049 /* Use the larger of the two minimums. */
1052 else
1055 /* Use the smaller of the two maximums. */
1058 else
1062 }
1063 else
1064 {
1065 /* The two ranges do not intersect, set the new range to
1066 VARYING, because we will not be able to do anything
1067 meaningful with it. */
1069 }
1070 }
1073 {
1074 /* A range and an anti-range will cancel each other only if
1075 their ends are the same. For instance, in the example above,
1076 p_8's range ~[0, 0] and p_6's range [0, 0] are incompatible,
1077 so VR_P should be set to VR_VARYING. */
1081 else
1082 {
1086 /* We want to compute the logical AND of the two ranges;
1087 there are three cases to consider.
1090 1. The VR_ANTI_RANGE range is completely within the
1091 VR_RANGE and the endpoints of the ranges are
1092 different. In that case the resulting range
1093 should be whichever range is more precise.
1094 Typically that will be the VR_RANGE.
1096 2. The VR_ANTI_RANGE is completely disjoint from
1097 the VR_RANGE. In this case the resulting range
1098 should be the VR_RANGE.
1100 3. There is some overlap between the VR_ANTI_RANGE
1101 and the VR_RANGE.
1103 3a. If the high limit of the VR_ANTI_RANGE resides
1104 within the VR_RANGE, then the result is a new
1105 VR_RANGE starting at the high limit of the
1106 the VR_ANTI_RANGE + 1 and extending to the
1107 high limit of the original VR_RANGE.
1109 3b. If the low limit of the VR_ANTI_RANGE resides
1110 within the VR_RANGE, then the result is a new
1111 VR_RANGE starting at the low limit of the original
1112 VR_RANGE and extending to the low limit of the
1113 VR_ANTI_RANGE - 1. */
1115 {
1120 }
1121 else
1122 {
1127 }
1130 /* Case 1, VR_ANTI_RANGE completely within VR_RANGE,
1131 not including any endpoints. */
1134 {
1137 }
1138 /* Case 2, VR_ANTI_RANGE completely disjoint from
1139 VR_RANGE. */
1142 {
1145 }
1146 /* Case 3a, the anti-range extends into the low
1147 part of the real range. Thus creating a new
1148 low for the real range. */
1152 {
1154 anti_max,
1158 }
1159 /* Case 3b, the anti-range extends into the high
1160 part of the real range. Thus creating a new
1161 higher for the real range. */
1165 {
1167 anti_min,
1171 }
1172 }
1173 }
1174 }
1177 /* Extract range information from SSA name VAR and store it in VR. If
1178 VAR has an interesting range, use it. Otherwise, create the
1179 range [VAR, VAR] and return it. This is useful in situations where
1180 we may have conditionals testing values of VARYING names. For
1181 instance,
1183 x_3 = y_5;
1184 if (x_3 > y_5)
1185 ...
1187 Even if y_5 is deemed VARYING, we can determine that x_3 > y_5 is
1188 always false. */
1190 static void
1192 {
1197 else
1201 }
1204 /* Wrapper around int_const_binop. If the operation overflows and we
1205 are not using wrapping arithmetic, then adjust the result to be
1206 -INF or +INF depending on CODE, VAL1 and VAL2. */
1210 {
1211 tree res;
1215 /* If we are not using wrapping arithmetic, operate symbolically
1216 on -INF and +INF. */
1218 {
1222 /* Ensure that res = val1 [+*] val2 >= val1
1223 or that res = val1 - val2 <= val1. */
1228 {
1230 }
1231 /* Checking for multiplication overflow is done by dividing the
1232 output of the multiplication by the first input of the
1233 multiplication. If the result of that division operation is
1234 not equal to the second input of the multiplication, then the
1235 multiplication overflowed. */
1237 {
1239 res,
1245 }
1248 {
1251 }
1253 }
1257 {
1258 /* If the operation overflowed but neither VAL1 nor VAL2 are
1259 overflown, return -INF or +INF depending on the operation
1260 and the combination of signs of the operands. */
1264 /* Notice that we only need to handle the restricted set of
1265 operations handled by extract_range_from_binary_expr.
1266 Among them, only multiplication, addition and subtraction
1267 can yield overflow without overflown operands because we
1268 are working with integral types only... except in the
1269 case VAL1 = -INF and VAL2 = -1 which overflows to +INF
1270 for division too. */
1272 /* For multiplication, the sign of the overflow is given
1273 by the comparison of the signs of the operands. */
1275 /* For addition, the operands must be of the same sign
1276 to yield an overflow. Its sign is therefore that
1277 of one of the operands, for example the first. */
1279 /* For subtraction, the operands must be of different
1280 signs to yield an overflow. Its sign is therefore
1281 that of the first operand or the opposite of that
1282 of the second operand. A first operand of 0 counts
1283 as positive here, for the corner case 0 - (-INF),
1284 which overflows, but must yield +INF. */
1286 /* For division, the only case is -INF / -1 = +INF. */
1293 else
1295 }
1298 }
1301 /* Extract range information from a binary expression EXPR based on
1302 the ranges of each of its operands and the expression code. */
1304 static void
1306 {
1314 /* Not all binary expressions can be applied to ranges in a
1315 meaningful way. Handle only arithmetic operations. */
1331 {
1334 }
1336 /* Get value ranges for each operand. For constant operands, create
1337 a new value range with the operand to simplify processing. */
1343 else
1351 else
1354 /* If either range is UNDEFINED, so is the result. */
1356 {
1359 }
1361 /* The type of the resulting value range defaults to VR0.TYPE. */
1364 /* Refuse to operate on VARYING ranges, ranges of different kinds
1365 and symbolic ranges. As an exception, we allow BIT_AND_EXPR
1366 because we may be able to derive a useful range even if one of
1367 the operands is VR_VARYING or symbolic range. TODO, we may be
1368 able to derive anti-ranges in some cases. */
1377 {
1380 }
1382 /* Now evaluate the expression to determine the new range. */
1386 {
1387 /* For pointer types, we are really only interested in asserting
1388 whether the expression evaluates to non-NULL. FIXME, we used
1389 to gcc_assert (code == PLUS_EXPR || code == MINUS_EXPR), but
1390 ivopts is generating expressions with pointer multiplication
1391 in them. */
1393 {
1398 else
1400 }
1401 else
1402 {
1403 /* Subtracting from a pointer, may yield 0, so just drop the
1404 resulting range to varying. */
1406 }
1409 }
1411 /* For integer ranges, apply the operation to each end of the
1412 range and see what we end up with. */
1417 {
1418 /* If one of the operands is zero, we know that the whole
1419 expression evaluates zero. */
1427 {
1430 }
1431 /* If one of the operands is one, we know that the whole
1432 expression evaluates one. */
1440 {
1443 }
1449 {
1450 /* Boolean expressions cannot be folded with int_const_binop. */
1453 }
1454 else
1455 {
1456 /* The result of a TRUTH_*_EXPR is always true or false. */
1459 }
1460 }
1464 {
1465 /* If we have a PLUS_EXPR with two VR_ANTI_RANGEs, drop to
1466 VR_VARYING. It would take more effort to compute a precise
1467 range for such a case. For example, if we have op0 == 1 and
1468 op1 == -1 with their ranges both being ~[0,0], we would have
1469 op0 + op1 == 0, so we cannot claim that the sum is in ~[0,0].
1470 Note that we are guaranteed to have vr0.type == vr1.type at
1471 this point. */
1473 {
1476 }
1478 /* For operations that make the resulting range directly
1479 proportional to the original ranges, apply the operation to
1480 the same end of each range. */
1483 }
1490 {
1494 /* If we have an unsigned MULT_EXPR with two VR_ANTI_RANGEs,
1495 drop to VR_VARYING. It would take more effort to compute a
1496 precise range for such a case. For example, if we have
1497 op0 == 65536 and op1 == 65536 with their ranges both being
1498 ~[0,0] on a 32-bit machine, we would have op0 * op1 == 0, so
1499 we cannot claim that the product is in ~[0,0]. Note that we
1500 are guaranteed to have vr0.type == vr1.type at this
1501 point. */
1505 {
1508 }
1510 /* Multiplications and divisions are a bit tricky to handle,
1511 depending on the mix of signs we have in the two ranges, we
1512 need to operate on different values to get the minimum and
1513 maximum values for the new range. One approach is to figure
1514 out all the variations of range combinations and do the
1515 operations.
1517 However, this involves several calls to compare_values and it
1518 is pretty convoluted. It's simpler to do the 4 operations
1519 (MIN0 OP MIN1, MIN0 OP MAX1, MAX0 OP MIN1 and MAX0 OP MAX0 OP
1520 MAX1) and then figure the smallest and largest values to form
1521 the new range. */
1523 /* Divisions by zero result in a VARYING value. */
1526 {
1529 }
1531 /* Compute the 4 cross operations. */
1546 /* Set MIN to the minimum of VAL[i] and MAX to the maximum
1547 of VAL[i]. */
1551 {
1557 {
1559 {
1560 /* If we found an overflowed value, set MIN and MAX
1561 to it so that we set the resulting range to
1562 VARYING. */
1565 }
1572 }
1573 }
1574 }
1576 {
1577 /* If we have a MINUS_EXPR with two VR_ANTI_RANGEs, drop to
1578 VR_VARYING. It would take more effort to compute a precise
1579 range for such a case. For example, if we have op0 == 1 and
1580 op1 == 1 with their ranges both being ~[0,0], we would have
1581 op0 - op1 == 0, so we cannot claim that the difference is in
1582 ~[0,0]. Note that we are guaranteed to have
1583 vr0.type == vr1.type at this point. */
1585 {
1588 }
1590 /* For MINUS_EXPR, apply the operation to the opposite ends of
1591 each range. */
1594 }
1596 {
1601 {
1604 }
1609 {
1613 }
1614 else
1615 {
1618 }
1619 }
1620 else
1623 /* If either MIN or MAX overflowed, then set the resulting range to
1624 VARYING. */
1627 {
1630 }
1634 {
1635 /* If the new range has its limits swapped around (MIN > MAX),
1636 then the operation caused one of them to wrap around, mark
1637 the new range VARYING. */
1639 }
1640 else
1642 }
1645 /* Extract range information from a unary expression EXPR based on
1646 the range of its operand and the expression code. */
1648 static void
1650 {
1656 /* Refuse to operate on certain unary expressions for which we
1657 cannot easily determine a resulting range. */
1663 {
1666 }
1668 /* Get value ranges for the operand. For constant operands, create
1669 a new value range with the operand to simplify processing. */
1675 else
1678 /* If VR0 is UNDEFINED, so is the result. */
1680 {
1683 }
1685 /* Refuse to operate on symbolic ranges, or if neither operand is
1686 a pointer or integral type. */
1691 {
1694 }
1696 /* If the expression involves pointers, we are only interested in
1697 determining if it evaluates to NULL [0, 0] or non-NULL (~[0, 0]). */
1699 {
1704 else
1708 }
1710 /* Handle unary expressions on integer ranges. */
1712 {
1716 /* If VR0 represents a simple range, then try to convert
1717 the min and max values for the range to the same type
1718 as OUTER_TYPE. If the results compare equal to VR0's
1719 min and max values and the new min is still less than
1720 or equal to the new max, then we can safely use the newly
1721 computed range for EXPR. This allows us to compute
1722 accurate ranges through many casts. */
1726 {
1729 /* Convert the input operand min/max to OUTER_TYPE. If
1730 the input has no range information, then use the min/max
1731 for the input's type. */
1733 {
1736 }
1737 else
1738 {
1741 }
1746 /* Verify the new min/max values are gimple values and
1747 that they compare equal to the original input's
1748 min/max values. */
1755 {
1758 }
1759 }
1761 /* When converting types of different sizes, set the result to
1762 VARYING. Things like sign extensions and precision loss may
1763 change the range. For instance, if x_3 is of type 'long long
1764 int' and 'y_5 = (unsigned short) x_3', if x_3 is ~[0, 0], it
1765 is impossible to know at compile time whether y_5 will be
1766 ~[0, 0]. */
1769 {
1772 }
1773 }
1775 /* Conversion of a VR_VARYING value to a wider type can result
1776 in a usable range. So wait until after we've handled conversions
1777 before dropping the result to VR_VARYING if we had a source
1778 operand that is VR_VARYING. */
1780 {
1783 }
1785 /* Apply the operation to each end of the range and see what we end
1786 up with. */
1789 {
1790 /* NEGATE_EXPR flips the range around. We need to treat
1791 TYPE_MIN_VALUE specially dependent on wrapping, range type
1792 and if it was used as minimum or maximum value:
1793 -~[MIN, MIN] == ~[MIN, MIN]
1794 -[MIN, 0] == [0, MAX] for -fno-wrapv
1795 -[MIN, 0] == [0, MIN] for -fwrapv (will be set to varying later) */
1807 }
1810 {
1812 {
1815 }
1816 else
1817 {
1820 else
1823 }
1824 }
1827 {
1828 /* -TYPE_MIN_VALUE = TYPE_MIN_VALUE with flag_wrapv so we can't get a
1829 useful range. */
1836 {
1839 }
1841 /* ABS_EXPR may flip the range around, if the original range
1842 included negative values. */
1851 /* If a VR_ANTI_RANGEs contains zero, then we have
1852 ~[-INF, min(MIN, MAX)]. */
1854 {
1856 {
1859 /* Take the lower of the two values. */
1863 /* Create ~[-INF, min (abs(MIN), abs(MAX))]
1864 or ~[-INF + 1, min (abs(MIN), abs(MAX))] when
1865 flag_wrapv is set and the original anti-range doesn't include
1866 TYPE_MIN_VALUE, remember -TYPE_MIN_VALUE = TYPE_MIN_VALUE. */
1870 type_min_value,
1873 }
1874 else
1875 {
1876 /* All else has failed, so create the range [0, INF], even for
1877 flag_wrapv since TYPE_MIN_VALUE is in the original
1878 anti-range. */
1882 }
1883 }
1885 /* If the range contains zero then we know that the minimum value in the
1886 range will be zero. */
1888 {
1892 }
1893 else
1894 {
1895 /* If the range was reversed, swap MIN and MAX. */
1897 {
1901 }
1902 }
1903 }
1904 else
1905 {
1906 /* Otherwise, operate on each end of the range. */
1909 }
1913 {
1914 /* If the new range has its limits swapped around (MIN > MAX),
1915 then the operation caused one of them to wrap around, mark
1916 the new range VARYING. */
1918 }
1919 else
1921 }
1924 /* Extract range information from a conditional expression EXPR based on
1925 the ranges of each of its operands and the expression code. */
1927 static void
1929 {
1934 /* Get value ranges for each operand. For constant operands, create
1935 a new value range with the operand to simplify processing. */
1941 else
1949 else
1952 /* The resulting value range is the union of the operand ranges */
1955 }
1958 /* Extract range information from a comparison expression EXPR based
1959 on the range of its operand and the expression code. */
1961 static void
1963 {
1966 {
1967 /* Since this expression was found on the RHS of an assignment,
1968 its type may be different from _Bool. Convert VAL to EXPR's
1969 type. */
1972 }
1973 else
1974 /* The result of a comparison is always true or false. */
1976 }
1979 /* Try to compute a useful range out of expression EXPR and store it
1980 in *VR. */
1982 static void
1984 {
2006 else
2009 /* If we got a varying range from the tests above, try a final
2010 time to derive a nonnegative or nonzero range. This time
2011 relying primarily on generic routines in fold in conjunction
2012 with range data. */
2014 {
2020 }
2021 }
2023 /* Given a range VR, a LOOP and a variable VAR, determine whether it
2024 would be profitable to adjust VR using scalar evolution information
2025 for VAR. If so, update VR with the new limits. */
2027 static void
2029 tree var)
2030 {
2034 /* TODO. Don't adjust anti-ranges. An anti-range may provide
2035 better opportunities than a regular range, but I'm not sure. */
2046 /* If STEP is symbolic, we can't know whether INIT will be the
2047 minimum or maximum value in the range. Also, unless INIT is
2048 a simple expression, compare_values and possibly other functions
2049 in tree-vrp won't be able to handle it. */
2057 or decreases, ... */
2058 dir == EV_DIR_UNKNOWN
2059 /* ... or if it may wrap. */
2067 else
2071 else
2075 {
2079 /* For VARYING or UNDEFINED ranges, just about anything we get
2080 from scalar evolutions should be better. */
2084 else
2087 /* If we would create an invalid range, then just assume we
2088 know absolutely nothing. This may be over-conservative,
2089 but it's clearly safe, and should happen only in unreachable
2090 parts of code, or for invalid programs. */
2095 }
2097 {
2102 {
2103 /* INIT is the maximum value. If INIT is lower than VR->MAX
2104 but no smaller than VR->MIN, set VR->MAX to INIT. */
2106 {
2109 /* If we just created an invalid range with the minimum
2110 greater than the maximum, we fail conservatively.
2111 This should happen only in unreachable
2112 parts of code, or for invalid programs. */
2115 }
2116 }
2117 else
2118 {
2119 /* If INIT is bigger than VR->MIN, set VR->MIN to INIT. */
2121 {
2124 /* Again, avoid creating invalid range by failing. */
2127 }
2128 }
2131 }
2132 }
2135 /* Given two numeric value ranges VR0, VR1 and a comparison code COMP:
2137 - Return BOOLEAN_TRUE_NODE if VR0 COMP VR1 always returns true for
2138 all the values in the ranges.
2140 - Return BOOLEAN_FALSE_NODE if the comparison always returns false.
2142 - Return NULL_TREE if it is not always possible to determine the
2143 value of the comparison. */
2146 static tree
2148 {
2149 /* VARYING or UNDEFINED ranges cannot be compared. */
2156 /* Anti-ranges need to be handled separately. */
2158 {
2159 /* If both are anti-ranges, then we cannot compute any
2160 comparison. */
2164 /* These comparisons are never statically computable. */
2171 /* Equality can be computed only between a range and an
2172 anti-range. ~[VAL1, VAL2] == [VAL1, VAL2] is always false. */
2174 {
2175 /* To simplify processing, make VR0 the anti-range. */
2179 }
2188 }
2190 /* Simplify processing. If COMP is GT_EXPR or GE_EXPR, switch the
2191 operands around and change the comparison code. */
2193 {
2199 }
2202 {
2203 /* Equality may only be computed if both ranges represent
2204 exactly one value. */
2207 {
2214 }
2215 /* If [V0_MIN, V1_MAX] < [V1_MIN, V1_MAX] then V0 != V1. */
2221 }
2223 {
2226 /* If VR0 is completely to the left or completely to the right
2227 of VR1, they are always different. Notice that we need to
2228 make sure that both comparisons yield similar results to
2229 avoid comparing values that cannot be compared at
2230 compile-time. */
2236 /* If VR0 and VR1 represent a single value and are identical,
2237 return false. */
2244 /* Otherwise, they may or may not be different. */
2245 else
2247 }
2249 {
2252 /* If VR0 is to the left of VR1, return true. */
2258 /* If VR0 is to the right of VR1, return false. */
2264 /* Otherwise, we don't know. */
2266 }
2269 }
2272 /* Given a value range VR, a value VAL and a comparison code COMP, return
2273 BOOLEAN_TRUE_NODE if VR COMP VAL always returns true for all the
2274 values in VR. Return BOOLEAN_FALSE_NODE if the comparison
2275 always returns false. Return NULL_TREE if it is not always
2276 possible to determine the value of the comparison. */
2278 static tree
2280 {
2284 /* Anti-ranges need to be handled separately. */
2286 {
2287 /* For anti-ranges, the only predicates that we can compute at
2288 compile time are equality and inequality. */
2295 /* ~[VAL_1, VAL_2] OP VAL is known if VAL_1 <= VAL <= VAL_2. */
2300 }
2303 {
2304 /* EQ_EXPR may only be computed if VR represents exactly
2305 one value. */
2307 {
2313 }
2319 }
2321 {
2322 /* If VAL is not inside VR, then they are always different. */
2327 /* If VR represents exactly one value equal to VAL, then return
2328 false. */
2333 /* Otherwise, they may or may not be different. */
2335 }
2337 {
2340 /* If VR is to the left of VAL, return true. */
2346 /* If VR is to the right of VAL, return false. */
2352 /* Otherwise, we don't know. */
2354 }
2356 {
2359 /* If VR is to the right of VAL, return true. */
2365 /* If VR is to the left of VAL, return false. */
2371 /* Otherwise, we don't know. */
2373 }
2376 }
2379 /* Debugging dumps. */
2389 /* Dump value range VR to FILE. */
2391 void
2393 {
2399 {
2408 else
2416 else
2422 {
2423 bitmap_iterator bi;
2429 {
2432 c++;
2433 }
2436 }
2437 }
2440 else
2442 }
2445 /* Dump value range VR to stderr. */
2447 void
2449 {
2452 }
2455 /* Dump value ranges of all SSA_NAMEs to FILE. */
2457 void
2459 {
2463 {
2465 {
2470 }
2471 }
2474 }
2477 /* Dump all value ranges to stderr. */
2479 void
2481 {
2483 }
2486 /* Given a COND_EXPR COND of the form 'V OP W', and an SSA name V,
2487 create a new SSA name N and return the assertion assignment
2488 'V = ASSERT_EXPR <V, V OP W>'. */
2490 static tree
2492 {
2499 {
2502 }
2504 {
2505 /* Given !V, build the assignment N = false. */
2509 boolean_false_node);
2510 }
2512 {
2513 /* Given V, build the assignment N = true. */
2517 }
2518 else
2523 /* The new ASSERT_EXPR, creates a new SSA name that replaces the
2524 operand of the ASSERT_EXPR. Register the new name and the old one
2525 in the replacement table so that we can fix the SSA web after
2526 adding all the ASSERT_EXPRs. */
2530 }
2533 /* Return false if EXPR is a predicate expression involving floating
2534 point values. */
2538 {
2541 }
2544 /* If the range of values taken by OP can be inferred after STMT executes,
2545 return the comparison code (COMP_CODE_P) and value (VAL_P) that
2546 describes the inferred range. Return true if a range could be
2547 inferred. */
2549 static bool
2551 {
2555 /* Do not attempt to infer anything in names that flow through
2556 abnormal edges. */
2560 /* Similarly, don't infer anything from statements that may throw
2561 exceptions. */
2565 /* If STMT is the last statement of a basic block with no
2566 successors, there is no point inferring anything about any of its
2567 operands. We would not be able to find a proper insertion point
2568 for the assertion, anyway. */
2572 /* We can only assume that a pointer dereference will yield
2573 non-NULL if -fdelete-null-pointer-checks is enabled. */
2575 {
2581 {
2585 }
2586 }
2589 }
2597 /* Dump all the registered assertions for NAME to FILE. */
2599 void
2601 {
2602 assert_locus_t loc;
2610 {
2615 {
2619 }
2626 }
2629 }
2632 /* Dump all the registered assertions for NAME to stderr. */
2634 void
2636 {
2638 }
2641 /* Dump all the registered assertions for all the names to FILE. */
2643 void
2645 {
2647 bitmap_iterator bi;
2653 }
2656 /* Dump all the registered assertions for all the names to stderr. */
2658 void
2660 {
2662 }
2665 /* If NAME doesn't have an ASSERT_EXPR registered for asserting
2666 'NAME COMP_CODE VAL' at a location that dominates block BB or
2667 E->DEST, then register this location as a possible insertion point
2668 for ASSERT_EXPR <NAME, NAME COMP_CODE VAL>.
2670 BB, E and SI provide the exact insertion point for the new
2671 ASSERT_EXPR. If BB is NULL, then the ASSERT_EXPR is to be inserted
2672 on edge E. Otherwise, if E is NULL, the ASSERT_EXPR is inserted on
2673 BB. If SI points to a COND_EXPR or a SWITCH_EXPR statement, then E
2674 must not be NULL. */
2676 static void
2679 tree val,
2680 basic_block bb,
2681 edge e,
2682 block_stmt_iterator si)
2683 {
2686 basic_block dest_bb;
2688 #if defined ENABLE_CHECKING
2694 #endif
2696 /* The new assertion A will be inserted at BB or E. We need to
2697 determine if the new location is dominated by a previously
2698 registered location for A. If we are doing an edge insertion,
2699 assume that A will be inserted at E->DEST. Note that this is not
2700 necessarily true.
2702 If E is a critical edge, it will be split. But even if E is
2703 split, the new block will dominate the same set of blocks that
2704 E->DEST dominates.
2706 The reverse, however, is not true, blocks dominated by E->DEST
2707 will not be dominated by the new block created to split E. So,
2708 if the insertion location is on a critical edge, we will not use
2709 the new location to move another assertion previously registered
2710 at a block dominated by E->DEST. */
2713 /* If NAME already has an ASSERT_EXPR registered for COMP_CODE and
2714 VAL at a block dominating DEST_BB, then we don't need to insert a new
2715 one. Similarly, if the same assertion already exists at a block
2716 dominated by DEST_BB and the new location is not on a critical
2717 edge, then update the existing location for the assertion (i.e.,
2718 move the assertion up in the dominance tree).
2720 Note, this is implemented as a simple linked list because there
2721 should not be more than a handful of assertions registered per
2722 name. If this becomes a performance problem, a table hashed by
2723 COMP_CODE and VAL could be implemented. */
2728 {
2732 {
2733 /* If the assertion NAME COMP_CODE VAL has already been
2734 registered at a basic block that dominates DEST_BB, then
2735 we don't need to insert the same assertion again. Note
2736 that we don't check strict dominance here to avoid
2737 replicating the same assertion inside the same basic
2738 block more than once (e.g., when a pointer is
2739 dereferenced several times inside a block).
2741 An exception to this rule are edge insertions. If the
2742 new assertion is to be inserted on edge E, then it will
2743 dominate all the other insertions that we may want to
2744 insert in DEST_BB. So, if we are doing an edge
2745 insertion, don't do this dominance check. */
2750 /* Otherwise, if E is not a critical edge and DEST_BB
2751 dominates the existing location for the assertion, move
2752 the assertion up in the dominance tree by updating its
2753 location information. */
2756 {
2761 }
2762 }
2764 /* Update the last node of the list and move to the next one. */
2767 }
2769 /* If we didn't find an assertion already registered for
2770 NAME COMP_CODE VAL, add a new one at the end of the list of
2771 assertions associated with NAME. */
2782 else
2786 }
2788 /* COND is a predicate which uses NAME. Extract a suitable test code
2789 and value and store them into *CODE_P and *VAL_P so the predicate
2790 is normalized to NAME *CODE_P *VAL_P.
2792 If no extraction was possible, return FALSE, otherwise return TRUE.
2794 If INVERT is true, then we invert the result stored into *CODE_P. */
2796 static bool
2799 {
2801 tree val;
2803 /* Predicates may be a single SSA name or NAME OP VAL. */
2805 {
2806 /* If the predicate is a name, it must be NAME, in which
2807 case we create the predicate NAME == true or
2808 NAME == false accordingly. */
2811 }
2812 else
2813 {
2814 /* Otherwise, we have a comparison of the form NAME COMP VAL
2815 or VAL COMP NAME. */
2817 {
2818 /* If the predicate is of the form VAL COMP NAME, flip
2819 COMP around because we need to register NAME as the
2820 first operand in the predicate. */
2823 }
2824 else
2825 {
2826 /* The comparison is of the form NAME COMP VAL, so the
2827 comparison code remains unchanged. */
2830 }
2832 /* Invert the comparison code as necessary. */
2836 /* VRP does not handle float types. */
2840 /* Do not register always-false predicates.
2841 FIXME: this works around a limitation in fold() when dealing with
2842 enumerations. Given 'enum { N1, N2 } x;', fold will not
2843 fold 'if (x > N2)' to 'if (0)'. */
2846 {
2851 && (!max
2856 && (!min
2859 }
2860 }
2864 }
2866 /* OP is an operand of a truth value expression which is known to have
2867 a particular value. Register any asserts for OP and for any
2868 operands in OP's defining statement.
2870 If CODE is EQ_EXPR, then we want to register OP is zero (false),
2871 if CODE is NE_EXPR, then we want to register OP is nonzero (true). */
2873 static bool
2876 {
2880 /* We only care about SSA_NAMEs. */
2884 /* We know that OP will have a zero or nonzero value. If OP is used
2885 more than once go ahead and register an assert for OP.
2887 The FOUND_IN_SUBGRAPH support is not helpful in this situation as
2888 it will always be set for OP (because OP is used in a COND_EXPR in
2889 the subgraph). */
2891 {
2895 }
2897 /* Now look at how OP is set. If it's set from a comparison,
2898 a truth operation or some bit operations, then we may be able
2899 to register information about the operands of that assignment. */
2907 {
2912 /* Conditionally register an assert for each SSA_NAME in the
2913 comparison. */
2918 {
2921 }
2923 /* Similarly for the second operand of the comparison. */
2928 {
2931 }
2932 }
2939 {
2940 /* Recurse on each operand. */
2945 }
2947 {
2948 /* Recurse, flipping CODE. */
2952 }
2954 {
2955 /* Recurse through the copy. */
2957 }
2962 {
2963 /* Recurse through the type conversion. */
2966 }
2969 }
2971 /* Try to register an edge assertion for SSA name NAME on edge E for
2972 the condition COND contributing to the conditional jump pointed to by SI.
2973 Return true if an assertion for NAME could be registered. */
2975 static bool
2977 {
2978 tree val;
2983 /* Do not attempt to infer anything in names that flow through
2984 abnormal edges. */
2992 /* Only register an ASSERT_EXPR if NAME was found in the sub-graph
2993 reachable from E. */
2995 {
2998 }
3000 /* If COND is effectively an equality test of an SSA_NAME against
3001 the value zero or one, then we may be able to assert values
3002 for SSA_NAMEs which flow into COND. */
3004 /* In the case of NAME == 1 or NAME != 0, for TRUTH_AND_EXPR defining
3005 statement of NAME we can assert both operands of the TRUTH_AND_EXPR
3006 have nonzero value. */
3009 {
3015 {
3020 }
3021 }
3023 /* In the case of NAME == 0 or NAME != 1, for TRUTH_OR_EXPR defining
3024 statement of NAME we can assert both operands of the TRUTH_OR_EXPR
3025 have zero value. */
3028 {
3034 {
3039 }
3040 }
3043 }
3048 /* Determine whether the outgoing edges of BB should receive an
3049 ASSERT_EXPR for each of the operands of BB's LAST statement.
3050 The last statement of BB must be a COND_EXPR or a SWITCH_EXPR.
3052 If any of the sub-graphs rooted at BB have an interesting use of
3053 the predicate operands, an assert location node is added to the
3054 list of assertions for the corresponding operands. */
3056 static bool
3058 {
3060 block_stmt_iterator bsi;
3061 tree op;
3062 edge_iterator ei;
3063 edge e;
3064 ssa_op_iter iter;
3069 /* Look for uses of the operands in each of the sub-graphs
3070 rooted at BB. We need to check each of the outgoing edges
3071 separately, so that we know what kind of ASSERT_EXPR to
3072 insert. */
3074 {
3078 /* Remove the COND_EXPR operands from the FOUND_IN_SUBGRAPH bitmap.
3079 Otherwise, when we finish traversing each of the sub-graphs, we
3080 won't know whether the variables were found in the sub-graphs or
3081 if they had been found in a block upstream from BB.
3083 This is actually a bad idea is some cases, particularly jump
3084 threading. Consider a CFG like the following:
3086 0
3087 /|
3088 1 |
3089 \|
3090 2
3091 / \
3092 3 4
3094 Assume that one or more operands in the conditional at the
3095 end of block 0 are used in a conditional in block 2, but not
3096 anywhere in block 1. In this case we will not insert any
3097 assert statements in block 1, which may cause us to miss
3098 opportunities to optimize, particularly for jump threading. */
3102 /* Traverse the strictly dominated sub-graph rooted at E->DEST
3103 to determine if any of the operands in the conditional
3104 predicate are used. */
3108 /* Register the necessary assertions for each operand in the
3109 conditional predicate. */
3113 }
3115 /* Finally, indicate that we have found the operands in the
3116 conditional. */
3121 }
3124 /* Traverse all the statements in block BB looking for statements that
3125 may generate useful assertions for the SSA names in their operand.
3126 If a statement produces a useful assertion A for name N_i, then the
3127 list of assertions already generated for N_i is scanned to
3128 determine if A is actually needed.
3130 If N_i already had the assertion A at a location dominating the
3131 current location, then nothing needs to be done. Otherwise, the
3132 new location for A is recorded instead.
3134 1- For every statement S in BB, all the variables used by S are
3135 added to bitmap FOUND_IN_SUBGRAPH.
3137 2- If statement S uses an operand N in a way that exposes a known
3138 value range for N, then if N was not already generated by an
3139 ASSERT_EXPR, create a new assert location for N. For instance,
3140 if N is a pointer and the statement dereferences it, we can
3141 assume that N is not NULL.
3143 3- COND_EXPRs are a special case of #2. We can derive range
3144 information from the predicate but need to insert different
3145 ASSERT_EXPRs for each of the sub-graphs rooted at the
3146 conditional block. If the last statement of BB is a conditional
3147 expression of the form 'X op Y', then
3149 a) Remove X and Y from the set FOUND_IN_SUBGRAPH.
3151 b) If the conditional is the only entry point to the sub-graph
3152 corresponding to the THEN_CLAUSE, recurse into it. On
3153 return, if X and/or Y are marked in FOUND_IN_SUBGRAPH, then
3154 an ASSERT_EXPR is added for the corresponding variable.
3156 c) Repeat step (b) on the ELSE_CLAUSE.
3158 d) Mark X and Y in FOUND_IN_SUBGRAPH.
3160 For instance,
3162 if (a == 9)
3163 b = a;
3164 else
3165 b = c + 1;
3167 In this case, an assertion on the THEN clause is useful to
3168 determine that 'a' is always 9 on that edge. However, an assertion
3169 on the ELSE clause would be unnecessary.
3171 4- If BB does not end in a conditional expression, then we recurse
3172 into BB's dominator children.
3174 At the end of the recursive traversal, every SSA name will have a
3175 list of locations where ASSERT_EXPRs should be added. When a new
3176 location for name N is found, it is registered by calling
3177 register_new_assert_for. That function keeps track of all the
3178 registered assertions to prevent adding unnecessary assertions.
3179 For instance, if a pointer P_4 is dereferenced more than once in a
3180 dominator tree, only the location dominating all the dereference of
3181 P_4 will receive an ASSERT_EXPR.
3183 If this function returns true, then it means that there are names
3184 for which we need to generate ASSERT_EXPRs. Those assertions are
3185 inserted by process_assert_insertions.
3187 TODO. Handle SWITCH_EXPR. */
3189 static bool
3191 {
3192 block_stmt_iterator si;
3195 basic_block son;
3204 /* Traverse all PHI nodes in BB marking used operands. */
3206 {
3207 use_operand_p arg_p;
3208 ssa_op_iter i;
3211 {
3214 {
3217 }
3218 }
3219 }
3221 /* Traverse all the statements in BB marking used names and looking
3222 for statements that may infer assertions for their used operands. */
3225 {
3227 ssa_op_iter i;
3231 /* See if we can derive an assertion for any of STMT's operands. */
3233 {
3234 tree value;
3237 /* Mark OP in bitmap FOUND_IN_SUBGRAPH. If STMT is inside
3238 the sub-graph of a conditional block, when we return from
3239 this recursive walk, our parent will use the
3240 FOUND_IN_SUBGRAPH bitset to determine if one of the
3241 operands it was looking for was present in the sub-graph. */
3244 /* If OP is used in such a way that we can infer a value
3245 range for it, and we don't find a previous assertion for
3246 it, create a new assertion location node for OP. */
3248 {
3249 /* If we are able to infer a nonzero value range for OP,
3250 then walk backwards through the use-def chain to see if OP
3251 was set via a typecast.
3253 If so, then we can also infer a nonzero value range
3254 for the operand of the NOP_EXPR. */
3256 {
3261 && TREE_CODE
3263 && TREE_CODE
3266 && POINTER_TYPE_P
3270 {
3274 /* Note we want to register the assert for the
3275 operand of the NOP_EXPR after SI, not after the
3276 conversion. */
3278 {
3282 }
3283 }
3284 }
3286 /* If OP is used only once, namely in this STMT, don't
3287 bother creating an ASSERT_EXPR for it. Such an
3288 ASSERT_EXPR would do nothing but increase compile time. */
3290 {
3293 }
3294 }
3295 }
3297 /* Remember the last statement of the block. */
3299 }
3301 /* If BB's last statement is a conditional expression
3302 involving integer operands, recurse into each of the sub-graphs
3303 rooted at BB to determine if we need to add ASSERT_EXPRs. */
3310 /* Recurse into the dominator children of BB. */
3312 son;
3317 }
3320 /* Create an ASSERT_EXPR for NAME and insert it in the location
3321 indicated by LOC. Return true if we made any edge insertions. */
3323 static bool
3325 {
3326 /* Build the comparison expression NAME_i COMP_CODE VAL. */
3328 edge_iterator ei;
3329 edge e;
3335 {
3336 /* We have been asked to insert the assertion on an edge. This
3337 is used only by COND_EXPR and SWITCH_EXPR assertions. */
3338 #if defined ENABLE_CHECKING
3341 #endif
3345 }
3347 /* Otherwise, we can insert right after LOC->SI iff the
3348 statement must not be the last statement in the block. */
3351 {
3354 }
3356 /* If STMT must be the last statement in BB, we can only insert new
3357 assertions on the non-abnormal edge out of BB. Note that since
3358 STMT is not control flow, there may only be one non-abnormal edge
3359 out of BB. */
3362 {
3365 }
3368 }
3371 /* Process all the insertions registered for every name N_i registered
3372 in NEED_ASSERT_FOR. The list of assertions to be inserted are
3373 found in ASSERTS_FOR[i]. */
3375 static void
3377 {
3379 bitmap_iterator bi;
3387 {
3392 {
3397 num_asserts++;
3398 }
3399 }
3406 num_asserts);
3407 }
3410 /* Traverse the flowgraph looking for conditional jumps to insert range
3411 expressions. These range expressions are meant to provide information
3412 to optimizations that need to reason in terms of value ranges. They
3413 will not be expanded into RTL. For instance, given:
3415 x = ...
3416 y = ...
3417 if (x < y)
3418 y = x - 2;
3419 else
3420 x = y + 3;
3422 this pass will transform the code into:
3424 x = ...
3425 y = ...
3426 if (x < y)
3427 {
3428 x = ASSERT_EXPR <x, x < y>
3429 y = x - 2
3430 }
3431 else
3432 {
3433 y = ASSERT_EXPR <y, x <= y>
3434 x = y + 3
3435 }
3437 The idea is that once copy and constant propagation have run, other
3438 optimizations will be able to determine what ranges of values can 'x'
3439 take in different paths of the code, simply by checking the reaching
3440 definition of 'x'. */
3442 static void
3444 {
3445 edge e;
3446 edge_iterator ei;
3466 {
3469 }
3472 {
3475 }
3480 }
3482 /* Checks one ARRAY_REF in REF, located at LOCUS. Ignores flexible arrays
3483 and "struct" hacks. If VRP can determine that the
3484 array subscript is a constant, check if it is outside valid
3485 range. If the array subscript is a RANGE, warn if it is
3486 non-overlapping with valid range.
3487 IGNORE_OFF_BY_ONE is true if the ARRAY_REF is inside a ADDR_EXPR. */
3489 static void
3491 {
3500 /* Can not check flexible arrays. */
3504 /* Accesses after the end of arrays of size 0 (gcc
3505 extension) and 1 are likely intentional ("struct
3506 hack"). */
3513 {
3516 {
3519 }
3520 }
3523 {
3528 {
3532 }
3533 }
3537 && (!ignore_off_by_one
3539 up_bound,
3540 integer_one_node,
3542 up_sub)))
3543 {
3545 locus);
3547 }
3550 {
3552 locus);
3554 }
3555 }
3557 /* walk_tree() callback that checks if *TP is
3558 an ARRAY_REF inside an ADDR_EXPR (in which an array
3559 subscript one outside the valid range is allowed). Call
3560 check_array_ref for each ARRAY_REF found. The location is
3561 passed in DATA. */
3563 static tree
3565 {
3575 {
3576 use_operand_p op;
3577 tree use_stmt;
3580 /* Don't warn on statements like
3582 ssa_name = 500 + &array[-200]
3584 or
3586 ssa_name = &array[-200]
3587 other_name = ssa_name + 300;
3589 which are sometimes
3590 produced by other optimizing passes. */
3604 {
3608 }
3610 }
3613 }
3615 /* Walk over all statements of all reachable BBs and call check_array_bounds
3616 on them. */
3618 static void
3620 {
3621 basic_block bb;
3622 block_stmt_iterator si;
3625 {
3626 /* Skip bb's that are clearly unreachable. */
3628 {
3641 }
3645 }
3646 }
3648 /* Convert range assertion expressions into the implied copies and
3649 copy propagate away the copies. Doing the trivial copy propagation
3650 here avoids the need to run the full copy propagation pass after
3651 VRP.
3653 FIXME, this will eventually lead to copy propagation removing the
3654 names that had useful range information attached to them. For
3655 instance, if we had the assertion N_i = ASSERT_EXPR <N_j, N_j > 3>,
3656 then N_i will have the range [3, +INF].
3658 However, by converting the assertion into the implied copy
3659 operation N_i = N_j, we will then copy-propagate N_j into the uses
3660 of N_i and lose the range information. We may want to hold on to
3661 ASSERT_EXPRs a little while longer as the ranges could be used in
3662 things like jump threading.
3664 The problem with keeping ASSERT_EXPRs around is that passes after
3665 VRP need to handle them appropriately.
3667 Another approach would be to make the range information a first
3668 class property of the SSA_NAME so that it can be queried from
3669 any pass. This is made somewhat more complex by the need for
3670 multiple ranges to be associated with one SSA_NAME. */
3672 static void
3674 {
3675 basic_block bb;
3676 block_stmt_iterator si;
3678 /* Note that the BSI iterator bump happens at the bottom of the
3679 loop and no bump is necessary if we're removing the statement
3680 referenced by the current BSI. */
3683 {
3685 tree use_stmt;
3689 {
3692 use_operand_p use_p;
3693 imm_use_iterator iter;
3697 /* Propagate the RHS into every use of the LHS. */
3702 {
3705 }
3707 /* And finally, remove the copy, it is not needed. */
3710 }
3711 else
3713 }
3716 }
3719 /* Return true if STMT is interesting for VRP. */
3721 static bool
3723 {
3730 {
3734 /* In general, assignments with virtual operands are not useful
3735 for deriving ranges, with the obvious exception of calls to
3736 builtin functions. */
3746 }
3751 }
3754 /* Initialize local data structures for VRP. */
3756 static void
3758 {
3759 basic_block bb;
3764 {
3765 block_stmt_iterator si;
3766 tree phi;
3769 {
3771 {
3775 }
3776 else
3778 }
3781 {
3785 {
3786 ssa_op_iter i;
3787 tree def;
3791 }
3792 else
3793 {
3795 }
3796 }
3797 }
3798 }
3801 /* Visit assignment STMT. If it produces an interesting range, record
3802 the SSA name in *OUTPUT_P. */
3804 static enum ssa_prop_result
3806 {
3808 ssa_op_iter iter;
3813 /* We only keep track of ranges in integral and pointer types. */
3816 /* It is valid to have NULL MIN/MAX values on a type. See
3817 build_range_type. */
3821 {
3827 /* If STMT is inside a loop, we may be able to know something
3828 else about the range of LHS by examining scalar evolution
3829 information. */
3834 {
3838 {
3844 }
3850 }
3853 }
3855 /* Every other statement produces no useful ranges. */
3860 }
3863 /* Compare all the value ranges for names equivalent to VAR with VAL
3864 using comparison code COMP. Return the same value returned by
3865 compare_range_with_value. */
3867 static tree
3869 {
3870 bitmap_iterator bi;
3872 bitmap e;
3877 /* Get the set of equivalences for VAR. */
3880 /* Add VAR to its own set of equivalences so that VAR's value range
3881 is processed by this loop (otherwise, we would have to replicate
3882 the body of the loop just to check VAR's value range). */
3886 {
3889 /* If name N_i does not have a valid range, use N_i as its own
3890 range. This allows us to compare against names that may
3891 have N_i in their ranges. */
3893 {
3897 }
3901 {
3902 /* If we get different answers from different members
3903 of the equivalence set this check must be in a dead
3904 code region. Folding it to a trap representation
3905 would be correct here. For now just return don't-know. */
3908 {
3911 }
3913 }
3914 }
3916 /* Remove VAR from its own equivalence set. */
3922 /* We couldn't find a non-NULL value for the predicate. */
3924 }
3927 /* Given a comparison code COMP and names N1 and N2, compare all the
3928 ranges equivalent to N1 against all the ranges equivalent to N2
3929 to determine the value of N1 COMP N2. Return the same value
3930 returned by compare_ranges. */
3932 static tree
3934 {
3940 /* Compare the ranges of every name equivalent to N1 against the
3941 ranges of every name equivalent to N2. */
3945 /* Add N1 and N2 to their own set of equivalences to avoid
3946 duplicating the body of the loop just to check N1 and N2
3947 ranges. */
3951 /* If the equivalence sets have a common intersection, then the two
3952 names can be compared without checking their ranges. */
3954 {
3959 ? boolean_true_node
3961 }
3963 /* Otherwise, compare all the equivalent ranges. First, add N1 and
3964 N2 to their own set of equivalences to avoid duplicating the body
3965 of the loop just to check N1 and N2 ranges. */
3967 {
3970 /* If the range is VARYING or UNDEFINED, use the name itself. */
3972 {
3976 }
3980 {
3984 {
3988 }
3992 {
3993 /* If we get different answers from different members
3994 of the equivalence set this check must be in a dead
3995 code region. Folding it to a trap representation
3996 would be correct here. For now just return don't-know. */
3999 {
4003 }
4005 }
4006 }
4009 {
4013 }
4014 }
4016 /* None of the equivalent ranges are useful in computing this
4017 comparison. */
4021 }
4024 /* Given a conditional predicate COND, try to determine if COND yields
4025 true or false based on the value ranges of its operands. Return
4026 BOOLEAN_TRUE_NODE if the conditional always evaluates to true,
4027 BOOLEAN_FALSE_NODE if the conditional always evaluates to false, and,
4028 NULL if the conditional cannot be evaluated at compile time.
4030 If USE_EQUIV_P is true, the ranges of all the names equivalent with
4031 the operands in COND are used when trying to compute its value.
4032 This is only used during final substitution. During propagation,
4033 we only check the range of each variable and not its equivalents. */
4035 tree
4037 {
4042 {
4044 tree retval;
4048 else
4049 {
4052 }
4054 /* If COND has a known boolean range, return it. */
4058 /* Otherwise, if COND has a symbolic range of exactly one value,
4059 return it. */
4063 }
4064 else
4065 {
4069 /* We only deal with integral and pointer types. */
4075 {
4083 }
4084 else
4085 {
4098 }
4099 }
4101 /* Anything else cannot be computed statically. */
4103 }
4106 /* Visit conditional statement STMT. If we can determine which edge
4107 will be taken out of STMT's basic block, record it in
4108 *TAKEN_EDGE_P and return SSA_PROP_INTERESTING. Otherwise, return
4109 SSA_PROP_VARYING. */
4111 static enum ssa_prop_result
4113 {
4118 /* FIXME. Handle SWITCH_EXPRs. But first, the assert pass needs to
4119 add ASSERT_EXPRs for them. */
4126 {
4127 tree use;
4128 ssa_op_iter i;
4135 {
4140 }
4143 }
4145 /* Compute the value of the predicate COND by checking the known
4146 ranges of each of its operands.
4148 Note that we cannot evaluate all the equivalent ranges here
4149 because those ranges may not yet be final and with the current
4150 propagation strategy, we cannot determine when the value ranges
4151 of the names in the equivalence set have changed.
4153 For instance, given the following code fragment
4155 i_5 = PHI <8, i_13>
4156 ...
4157 i_14 = ASSERT_EXPR <i_5, i_5 != 0>
4158 if (i_14 == 1)
4159 ...
4161 Assume that on the first visit to i_14, i_5 has the temporary
4162 range [8, 8] because the second argument to the PHI function is
4163 not yet executable. We derive the range ~[0, 0] for i_14 and the
4164 equivalence set { i_5 }. So, when we visit 'if (i_14 == 1)' for
4165 the first time, since i_14 is equivalent to the range [8, 8], we
4166 determine that the predicate is always false.
4168 On the next round of propagation, i_13 is determined to be
4169 VARYING, which causes i_5 to drop down to VARYING. So, another
4170 visit to i_14 is scheduled. In this second visit, we compute the
4171 exact same range and equivalence set for i_14, namely ~[0, 0] and
4172 { i_5 }. But we did not have the previous range for i_5
4173 registered, so vrp_visit_assignment thinks that the range for
4174 i_14 has not changed. Therefore, the predicate 'if (i_14 == 1)'
4175 is not visited again, which stops propagation from visiting
4176 statements in the THEN clause of that if().
4178 To properly fix this we would need to keep the previous range
4179 value for the names in the equivalence set. This way we would've
4180 discovered that from one visit to the other i_5 changed from
4181 range [8, 8] to VR_VARYING.
4183 However, fixing this apparent limitation may not be worth the
4184 additional checking. Testing on several code bases (GCC, DLV,
4185 MICO, TRAMP3D and SPEC2000) showed that doing this results in
4186 4 more predicates folded in SPEC. */
4192 {
4196 else
4198 }
4201 }
4204 /* Evaluate statement STMT. If the statement produces a useful range,
4205 return SSA_PROP_INTERESTING and record the SSA name with the
4206 interesting range into *OUTPUT_P.
4208 If STMT is a conditional branch and we can determine its truth
4209 value, the taken edge is recorded in *TAKEN_EDGE_P.
4211 If STMT produces a varying value, return SSA_PROP_VARYING. */
4213 static enum ssa_prop_result
4215 {
4216 tree def;
4217 ssa_op_iter iter;
4218 stmt_ann_t ann;
4221 {
4225 }
4229 {
4232 /* In general, assignments with virtual operands are not useful
4233 for deriving ranges, with the obvious exception of calls to
4234 builtin functions. */
4241 }
4245 /* All other statements produce nothing of interest for VRP, so mark
4246 their outputs varying and prevent further simulation. */
4251 }
4254 /* Meet operation for value ranges. Given two value ranges VR0 and
4255 VR1, store in VR0 a range that contains both VR0 and VR1. This
4256 may not be the smallest possible such range. */
4258 static void
4260 {
4262 {
4265 }
4268 {
4269 /* Nothing to do. VR0 already has the resulting range. */
4271 }
4274 {
4275 /* Nothing to do. VR0 already has the resulting range. */
4277 }
4280 {
4283 }
4286 {
4290 /* Compute the convex hull of the ranges. The lower limit of
4291 the new range is the minimum of the two ranges. If they
4292 cannot be compared, then give up. */
4298 else
4301 /* Similarly, the upper limit of the new range is the maximum
4302 of the two ranges. If they cannot be compared, then
4303 give up. */
4309 else
4312 /* The resulting set of equivalences is the intersection of
4313 the two sets. */
4320 }
4322 {
4323 /* Two anti-ranges meet only if their complements intersect.
4324 Only handle the case of identical ranges. */
4328 {
4329 /* The resulting set of equivalences is the intersection of
4330 the two sets. */
4335 }
4336 else
4338 }
4340 {
4341 /* For a numeric range [VAL1, VAL2] and an anti-range ~[VAL3, VAL4],
4342 only handle the case where the ranges have an empty intersection.
4343 The result of the meet operation is the anti-range. */
4347 {
4348 /* Copy most of VR1 into VR0. Don't copy VR1's equivalence
4349 set. We need to compute the intersection of the two
4350 equivalence sets. */
4354 /* The resulting set of equivalences is the intersection of
4355 the two sets. */
4360 }
4361 else
4363 }
4364 else
4369 give_up:
4370 /* Failed to find an efficient meet. Before giving up and setting
4371 the result to VARYING, see if we can at least derive a useful
4372 anti-range. FIXME, all this nonsense about distinguishing
4373 anti-ranges from ranges is necessary because of the odd
4374 semantics of range_includes_zero_p and friends. */
4381 {
4384 /* Since this meet operation did not result from the meeting of
4385 two equivalent names, VR0 cannot have any equivalences. */
4388 }
4389 else
4391 }
4394 /* Visit all arguments for PHI node PHI that flow through executable
4395 edges. If a valid value range can be derived from all the incoming
4396 value ranges, set a new range for the LHS of PHI. */
4398 static enum ssa_prop_result
4400 {
4410 {
4413 }
4416 {
4420 {
4425 }
4428 {
4430 value_range_t vr_arg;
4433 {
4436 }
4437 else
4438 {
4443 }
4446 {
4452 }
4458 }
4459 }
4464 /* To prevent infinite iterations in the algorithm, derive ranges
4465 when the new value is slightly bigger or smaller than the
4466 previous one. */
4469 {
4471 {
4475 /* If the new minimum is smaller or larger than the previous
4476 one, go all the way to -INF. In the first case, to avoid
4477 iterating millions of times to reach -INF, and in the
4478 other case to avoid infinite bouncing between different
4479 minimums. */
4483 /* Similarly, if the new maximum is smaller or larger than
4484 the previous one, go all the way to +INF. */
4488 /* If we ended up with a (-INF, +INF) range, set it to
4489 VARYING. */
4493 }
4494 }
4496 /* If the new range is different than the previous value, keep
4497 iterating. */
4501 /* Nothing changed, don't add outgoing edges. */
4504 /* No match found. Set the LHS to VARYING. */
4505 varying:
4508 }
4510 /* Simplify a division or modulo operator to a right shift or
4511 bitwise and if the first operand is unsigned or is greater
4512 than zero and the second operand is an exact power of two. */
4514 static void
4516 {
4522 {
4524 }
4525 else
4526 {
4528 }
4531 {
4532 tree t;
4537 {
4540 }
4541 else
4542 {
4547 }
4551 }
4552 }
4554 /* If the operand to an ABS_EXPR is >= 0, then eliminate the
4555 ABS_EXPR. If the operand is <= 0, then simplify the
4556 ABS_EXPR into a NEGATE_EXPR. */
4558 static void
4560 {
4567 {
4569 }
4571 {
4574 {
4578 {
4583 }
4584 }
4588 {
4589 tree t;
4593 else
4598 }
4599 }
4600 }
4602 /* We are comparing trees OP0 and OP1 using COND_CODE. OP0 has
4603 a known value range VR.
4605 If there is one and only one value which will satisfy the
4606 conditional, then return that value. Else return NULL. */
4608 static tree
4611 {
4615 /* Extract minimum/maximum values which satisfy the
4616 the conditional as it was written. */
4618 {
4623 {
4626 }
4627 }
4629 {
4634 {
4637 }
4638 }
4640 /* Now refine the minimum and maximum values using any
4641 value range information we have for op0. */
4643 {
4646 else
4650 else
4653 /* If the new min/max values have converged to a single value,
4654 then there is only one value which can satisfy the condition,
4655 return that value. */
4658 }
4660 }
4662 /* Simplify a conditional using a relational operator to an equality
4663 test if the range information indicates only one value can satisfy
4664 the original conditional. */
4666 static void
4668 {
4679 {
4682 /* If we have range information for OP0, then we might be
4683 able to simplify this conditional. */
4685 {
4689 {
4691 {
4695 }
4702 {
4705 }
4708 }
4710 /* Try again after inverting the condition. We only deal
4711 with integral types here, so no need to worry about
4712 issues with inverting FP comparisons. */
4717 {
4719 {
4723 }
4730 {
4733 }
4736 }
4737 }
4738 }
4739 }
4741 /* Simplify STMT using ranges if possible. */
4743 void
4745 {
4747 {
4751 /* Transform TRUNC_DIV_EXPR and TRUNC_MOD_EXPR into RSHIFT_EXPR
4752 and BIT_AND_EXPR respectively if the first operand is greater
4753 than zero and the second operand is an exact power of two. */
4759 /* Transform ABS (X) into X or -X as appropriate. */
4764 }
4767 {
4769 }
4770 }
4772 /* Stack of dest,src equivalency pairs that need to be restored after
4773 each attempt to thread a block's incoming edge to an outgoing edge.
4775 A NULL entry is used to mark the end of pairs which need to be
4776 restored. */
4779 /* A trivial wrapper so that we can present the generic jump
4780 threading code with a simple API for simplifying statements. */
4781 static tree
4783 {
4784 /* We only use VRP information to simplify conditionals. This is
4785 overly conservative, but it's unclear if doing more would be
4786 worth the compile time cost. */
4791 }
4793 /* Blocks which have more than one predecessor and more than
4794 one successor present jump threading opportunities. ie,
4795 when the block is reached from a specific predecessor, we
4796 may be able to determine which of the outgoing edges will
4797 be traversed. When this optimization applies, we are able
4798 to avoid conditionals at runtime and we may expose secondary
4799 optimization opportunities.
4801 This routine is effectively a driver for the generic jump
4802 threading code. It basically just presents the generic code
4803 with edges that may be suitable for jump threading.
4805 Unlike DOM, we do not iterate VRP if jump threading was successful.
4806 While iterating may expose new opportunities for VRP, it is expected
4807 those opportunities would be very limited and the compile time cost
4808 to expose those opportunities would be significant.
4810 As jump threading opportunities are discovered, they are registered
4811 for later realization. */
4813 static void
4815 {
4816 basic_block bb;
4817 tree dummy;
4819 /* Ugh. When substituting values earlier in this pass we can
4820 wipe the dominance information. So rebuild the dominator
4821 information as we need it within the jump threading code. */
4824 /* We do not allow VRP information to be used for jump threading
4825 across a back edge in the CFG. Otherwise it becomes too
4826 difficult to avoid eliminating loop exit tests. Of course
4827 EDGE_DFS_BACK is not accurate at this time so we have to
4828 recompute it. */
4831 /* Allocate our unwinder stack to unwind any temporary equivalences
4832 that might be recorded. */
4835 /* To avoid lots of silly node creation, we create a single
4836 conditional and just modify it in-place when attempting to
4837 thread jumps. */
4841 /* Walk through all the blocks finding those which present a
4842 potential jump threading opportunity. We could set this up
4843 as a dominator walker and record data during the walk, but
4844 I doubt it's worth the effort for the classes of jump
4845 threading opportunities we are trying to identify at this
4846 point in compilation. */
4848 {
4851 /* If the generic jump threading code does not find this block
4852 interesting, then there is nothing to do. */
4856 /* We only care about blocks ending in a COND_EXPR. While there
4857 may be some value in handling SWITCH_EXPR here, I doubt it's
4858 terribly important. */
4863 /* We're basically looking for any kind of conditional with
4864 integral type arguments. */
4874 {
4875 edge_iterator ei;
4876 edge e;
4878 /* We've got a block with multiple predecessors and multiple
4879 successors which also ends in a suitable conditional. For
4880 each predecessor, see if we can thread it to a specific
4881 successor. */
4883 {
4884 /* Do not thread across back edges or abnormal edges
4885 in the CFG. */
4891 simplify_stmt_for_jump_threading);
4892 }
4893 }
4894 }
4896 /* We do not actually update the CFG or SSA graphs at this point as
4897 ASSERT_EXPRs are still in the IL and cfg cleanup code does not yet
4898 handle ASSERT_EXPRs gracefully. */
4899 }
4901 /* We identified all the jump threading opportunities earlier, but could
4902 not transform the CFG at that time. This routine transforms the
4903 CFG and arranges for the dominator tree to be rebuilt if necessary.
4905 Note the SSA graph update will occur during the normal TODO
4906 processing by the pass manager. */
4907 static void
4909 {
4913 /* If we threaded jumps, then we need to recompute the dominance
4914 information. */
4918 }
4921 /* Traverse all the blocks folding conditionals with known ranges. */
4923 static void
4925 {
4931 {
4935 }
4937 /* We may have ended with ranges that have exactly one value. Those
4938 values can be substituted as any other copy/const propagated
4939 value using substitute_and_fold. */
4947 {
4950 }
4953 {
4954 /* We found no single-valued ranges, don't waste time trying to
4955 do single value substitution in substitute_and_fold. */
4958 }
4965 /* We must identify jump threading opportunities before we release
4966 the datastructures built by VRP. */
4969 /* Free allocated memory. */
4972 {
4975 }
4980 /* So that we can distinguish between VRP data being available
4981 and not available. */
4983 }
4986 /* Main entry point to VRP (Value Range Propagation). This pass is
4987 loosely based on J. R. C. Patterson, ``Accurate Static Branch
4988 Prediction by Value Range Propagation,'' in SIGPLAN Conference on
4989 Programming Language Design and Implementation, pp. 67-78, 1995.
4990 Also available at http://citeseer.ist.psu.edu/patterson95accurate.html
4992 This is essentially an SSA-CCP pass modified to deal with ranges
4993 instead of constants.
4995 While propagating ranges, we may find that two or more SSA name
4996 have equivalent, though distinct ranges. For instance,
4998 1 x_9 = p_3->a;
4999 2 p_4 = ASSERT_EXPR <p_3, p_3 != 0>
5000 3 if (p_4 == q_2)
5001 4 p_5 = ASSERT_EXPR <p_4, p_4 == q_2>;
5002 5 endif
5003 6 if (q_2)
5005 In the code above, pointer p_5 has range [q_2, q_2], but from the
5006 code we can also determine that p_5 cannot be NULL and, if q_2 had
5007 a non-varying range, p_5's range should also be compatible with it.
5009 These equivalences are created by two expressions: ASSERT_EXPR and
5010 copy operations. Since p_5 is an assertion on p_4, and p_4 was the
5011 result of another assertion, then we can use the fact that p_5 and
5012 p_4 are equivalent when evaluating p_5's range.
5014 Together with value ranges, we also propagate these equivalences
5015 between names so that we can take advantage of information from
5016 multiple ranges when doing final replacement. Note that this
5017 equivalency relation is transitive but not symmetric.
5019 In the example above, p_5 is equivalent to p_4, q_2 and p_3, but we
5020 cannot assert that q_2 is equivalent to p_5 because q_2 may be used
5021 in contexts where that assertion does not hold (e.g., in line 6).
5023 TODO, the main difference between this pass and Patterson's is that
5024 we do not propagate edge probabilities. We only compute whether
5025 edges can be taken or not. That is, instead of having a spectrum
5026 of jump probabilities between 0 and 1, we only deal with 0, 1 and
5027 DON'T KNOW. In the future, it may be worthwhile to propagate
5028 probabilities to aid branch prediction. */
5030 static unsigned int
5032 {
5044 {
5047 }
5049 /* ASSERT_EXPRs must be removed before finalizing jump threads
5050 as finalizing jump threads calls the CFG cleanup code which
5051 does not properly handle ASSERT_EXPRs. */
5054 /* If we exposed any new variables, go ahead and put them into
5055 SSA form now, before we handle jump threading. This simplifies
5056 interactions between rewriting of _DECL nodes into SSA form
5057 and rewriting SSA_NAME nodes into SSA form after block
5058 duplication and CFG manipulation. */
5063 }
5065 static bool
5067 {
5069 }
5072 {
5084 TODO_cleanup_cfg
5085 | TODO_ggc_collect
5086 | TODO_verify_ssa
5087 | TODO_dump_func
5088 | TODO_update_ssa
5091 };