| blob | 9eac7e9b67deb8b2b03d6e86b5bfd7372bee56ab |
1 /* Support routines for Value Range Propagation (VRP).
2 Copyright (C) 2005, 2006 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. */
40 /* Set of SSA names found during the dominator traversal of a
41 sub-graph in find_assert_locations. */
44 /* Local functions. */
47 /* Location information for ASSERT_EXPRs. Each instance of this
48 structure describes an ASSERT_EXPR for an SSA name. Since a single
49 SSA name may have more than one assertion associated with it, these
50 locations are kept in a linked list attached to the corresponding
51 SSA name. */
52 struct assert_locus_d
53 {
54 /* Basic block where the assertion would be inserted. */
55 basic_block bb;
57 /* Some assertions need to be inserted on an edge (e.g., assertions
58 generated by COND_EXPRs). In those cases, BB will be NULL. */
59 edge e;
61 /* Pointer to the statement that generated this assertion. */
62 block_stmt_iterator si;
64 /* Predicate code for the ASSERT_EXPR. Must be COMPARISON_CLASS_P. */
67 /* Value being compared against. */
68 tree val;
70 /* Next node in the linked list. */
72 };
76 /* If bit I is present, it means that SSA name N_i has a list of
77 assertions that should be inserted in the IL. */
80 /* Array of locations lists where to insert assertions. ASSERTS_FOR[I]
81 holds a list of ASSERT_LOCUS_T nodes that describe where
82 ASSERT_EXPRs for SSA name N_I should be inserted. */
85 /* Set of blocks visited in find_assert_locations. Used to avoid
86 visiting the same block more than once. */
89 /* Value range array. After propagation, VR_VALUE[I] holds the range
90 of values that SSA name N_I may take. */
94 /* Return true if ARG is marked with the nonnull attribute in the
95 current function signature. */
97 static bool
99 {
108 /* If "nonnull" wasn't specified, we know nothing about the argument. */
112 /* If "nonnull" applies to all the arguments, then ARG is non-null. */
116 /* Get the position number for ARG in the function signature. */
118 t;
120 {
123 }
127 /* Now see if ARG_NUM is mentioned in the nonnull list. */
129 {
132 }
135 }
138 /* Set value range VR to {T, MIN, MAX, EQUIV}. */
140 static void
143 {
144 #if defined ENABLE_CHECKING
145 /* Check the validity of the range. */
147 {
158 }
165 #endif
171 /* Since updating the equivalence set involves deep copying the
172 bitmaps, only do it if absolutely necessary. */
177 {
180 else
182 }
183 }
186 /* Copy value range FROM into value range TO. */
190 {
192 }
194 /* Set value range VR to a non-negative range of type TYPE. */
198 {
201 }
203 /* Set value range VR to a non-NULL range of type TYPE. */
207 {
210 }
213 /* Set value range VR to a NULL range of type TYPE. */
217 {
220 }
223 /* Set value range VR to VR_VARYING. */
227 {
232 }
235 /* Set value range VR to VR_UNDEFINED. */
239 {
244 }
247 /* Return value range information for VAR.
249 If we have no values ranges recorded (ie, VRP is not running), then
250 return NULL. Otherwise create an empty range if none existed for VAR. */
254 {
256 tree sym;
259 /* If we have no recorded ranges, then return NULL. */
267 /* Create a default value range. */
271 /* Allocate an equivalence set. */
274 /* If VAR is a default definition, the variable can take any value
275 in VAR's type. */
278 {
279 /* Try to use the "nonnull" attribute to create ~[0, 0]
280 anti-ranges for pointers. Note that this is only valid with
281 default definitions of PARM_DECLs. */
286 else
288 }
291 }
294 /* Update the value range and equivalence set for variable VAR to
295 NEW_VR. Return true if NEW_VR is different from VAR's previous
296 value.
298 NOTE: This function assumes that NEW_VR is a temporary value range
299 object created for the sole purpose of updating VAR's range. The
300 storage used by the equivalence set from NEW_VR will be freed by
301 this function. Do not call update_value_range when NEW_VR
302 is the range object associated with another SSA name. */
306 {
310 /* Update the value range, if necessary. */
327 }
330 /* Add VAR and VAR's equivalence set to EQUIV. */
332 static void
334 {
341 }
344 /* Return true if VR is ~[0, 0]. */
348 {
352 }
355 /* Return true if VR is [0, 0]. */
359 {
363 }
366 /* Return true if value range VR involves at least one symbol. */
370 {
373 }
375 /* Like tree_expr_nonnegative_p, but this function uses value ranges
376 obtained so far. */
378 static bool
380 {
382 }
384 /* Like tree_expr_nonzero_p, but this function uses value ranges
385 obtained so far. */
387 static bool
389 {
393 /* If we have an expression of the form &X->a, then the expression
394 is nonnull if X is nonnull. */
396 {
402 {
406 }
407 }
410 }
412 /* Returns true if EXPR is a valid value (as expected by compare_values) --
413 a gimple invariant, or SSA_NAME +- CST. */
415 static bool
417 {
427 }
429 /* Compare two values VAL1 and VAL2. Return
431 -2 if VAL1 and VAL2 cannot be compared at compile-time,
432 -1 if VAL1 < VAL2,
433 0 if VAL1 == VAL2,
434 +1 if VAL1 > VAL2, and
435 +2 if VAL1 != VAL2
437 This is similar to tree_int_cst_compare but supports pointer values
438 and values that cannot be compared at compile time. */
440 static int
442 {
446 /* Below we rely on the fact that VAL1 and VAL2 are both pointers or
447 both integers. */
457 {
461 /* If VAL1 and VAL2 are of the form 'NAME [+-] CST' or 'NAME',
462 return -1 or +1 accordingly. If VAL1 and VAL2 don't use the
463 same name, return -2. */
465 {
469 }
470 else
471 {
476 {
481 }
482 }
485 {
489 }
490 else
491 {
496 {
501 }
502 }
504 /* Both values must use the same name. */
510 /* NAME == NAME */
513 /* If overflow is defined we cannot simplify more. */
519 {
521 /* NAME < NAME + CST */
524 /* NAME > NAME - CST */
526 }
528 {
530 /* NAME + CST > NAME */
533 /* NAME + CST1 > NAME + CST2, if CST1 > CST2 */
536 /* NAME + CST1 > NAME - CST2 */
538 }
540 {
542 /* NAME - CST < NAME */
545 /* NAME - CST1 < NAME + CST2 */
548 /* NAME - CST1 > NAME - CST2, if CST1 < CST2. Notice that
549 C1 and C2 are swapped in the call to compare_values. */
551 }
554 }
556 /* We cannot compare non-constants. */
561 {
562 /* We cannot compare overflowed values. */
567 }
568 else
569 {
570 tree t;
572 /* First see if VAL1 and VAL2 are not the same. */
576 /* If VAL1 is a lower address than VAL2, return -1. */
581 /* If VAL1 is a higher address than VAL2, return +1. */
586 /* If VAL1 is different than VAL2, return +2. */
592 }
593 }
596 /* Return 1 if VAL is inside value range VR (VR->MIN <= VAL <= VR->MAX),
597 0 if VAL is not inside VR,
598 -2 if we cannot tell either way.
600 FIXME, the current semantics of this functions are a bit quirky
601 when taken in the context of VRP. In here we do not care
602 about VR's type. If VR is the anti-range ~[3, 5] the call
603 value_inside_range (4, VR) will return 1.
605 This is counter-intuitive in a strict sense, but the callers
606 currently expect this. They are calling the function
607 merely to determine whether VR->MIN <= VAL <= VR->MAX. The
608 callers are applying the VR_RANGE/VR_ANTI_RANGE semantics
609 themselves.
611 This also applies to value_ranges_intersect_p and
612 range_includes_zero_p. The semantics of VR_RANGE and
613 VR_ANTI_RANGE should be encoded here, but that also means
614 adapting the users of these functions to the new semantics. */
618 {
630 }
633 /* Return true if value ranges VR0 and VR1 have a non-empty
634 intersection. */
638 {
643 }
646 /* Return true if VR includes the value zero, false otherwise. FIXME,
647 currently this will return false for an anti-range like ~[-4, 3].
648 This will be wrong when the semantics of value_inside_range are
649 modified (currently the users of this function expect these
650 semantics). */
654 {
655 tree zero;
663 }
665 /* Return true if T, an SSA_NAME, is known to be nonnegative. Return
666 false otherwise or if no value range information is available. */
668 bool
670 {
676 /* Testing for VR_ANTI_RANGE is not useful here as any anti-range
677 which would return a useful value should be encoded as a VR_RANGE. */
679 {
683 }
685 }
687 /* Return true if T, an SSA_NAME, is known to be nonzero. Return
688 false otherwise or if no value range information is available. */
690 bool
692 {
698 /* A VR_RANGE which does not include zero is a nonzero value. */
702 /* A VR_ANTI_RANGE which does include zero is a nonzero value. */
707 }
710 /* When extracting ranges from X_i = ASSERT_EXPR <Y_j, pred>, we will
711 initially consider X_i and Y_j equivalent, so the equivalence set
712 of Y_j is added to the equivalence set of X_i. However, it is
713 possible to have a chain of ASSERT_EXPRs whose predicates are
714 actually incompatible. This is usually the result of nesting of
715 contradictory if-then-else statements. For instance, in PR 24670:
717 count_4 has range [-INF, 63]
719 if (count_4 != 0)
720 {
721 count_19 = ASSERT_EXPR <count_4, count_4 != 0>
722 if (count_19 > 63)
723 {
724 count_18 = ASSERT_EXPR <count_19, count_19 > 63>
725 if (count_18 <= 63)
726 ...
727 }
728 }
730 Notice that 'if (count_19 > 63)' is trivially false and will be
731 folded out at the end. However, during propagation, the flowgraph
732 is not cleaned up and so, VRP will evaluate predicates more
733 predicates than necessary, so it must support these
734 inconsistencies. The problem here is that because of the chaining
735 of ASSERT_EXPRs, the equivalency set for count_18 includes count_4.
736 Since count_4 has an incompatible range, we ICE when evaluating the
737 ranges in the equivalency set. So, we need to remove count_4 from
738 it. */
740 static void
742 {
743 bitmap_iterator bi;
748 /* Only detect inconsistencies on numeric ranges. */
755 {
769 {
770 /* A range and an anti-range have an empty intersection if
771 their end points are the same. FIXME,
772 value_ranges_intersect_p should handle this
773 automatically. */
777 }
778 }
782 }
785 /* Extract value range information from an ASSERT_EXPR EXPR and store
786 it in *VR_P. */
788 static void
790 {
800 /* Find VAR in the ASSERT_EXPR conditional. */
802 {
803 /* If the predicate is of the form VAR COMP LIMIT, then we just
804 take LIMIT from the RHS and use the same comparison code. */
807 }
808 else
809 {
810 /* If the predicate is of the form LIMIT COMP VAR, then we need
811 to flip around the comparison code to create the proper range
812 for VAR. */
815 }
820 /* For pointer arithmetic, we only keep track of pointer equality
821 and inequality. */
823 {
826 }
828 /* If LIMIT is another SSA name and LIMIT has a range of its own,
829 try to use LIMIT's range to avoid creating symbolic ranges
830 unnecessarily. */
833 /* LIMIT's range is only interesting if it has any useful information. */
840 /* Initially, the new range has the same set of equivalences of
841 VAR's range. This will be revised before returning the final
842 value. Since assertions may be chained via mutually exclusive
843 predicates, we will need to trim the set of equivalences before
844 we are done. */
849 /* Extract a new range based on the asserted comparison for VAR and
850 LIMIT's value range. Notice that if LIMIT has an anti-range, we
851 will only use it for equality comparisons (EQ_EXPR). For any
852 other kind of assertion, we cannot derive a range from LIMIT's
853 anti-range that can be used to describe the new range. For
854 instance, ASSERT_EXPR <x_2, x_2 <= b_4>. If b_4 is ~[2, 10],
855 then b_4 takes on the ranges [-INF, 1] and [11, +INF]. There is
856 no single range for x_2 that could describe LE_EXPR, so we might
857 as well build the range [b_4, +INF] for it. */
859 {
863 {
867 }
868 else
869 {
873 }
877 /* When asserting the equality VAR == LIMIT and LIMIT is another
878 SSA name, the new range will also inherit the equivalence set
879 from LIMIT. */
882 }
884 {
885 /* As described above, when LIMIT's range is an anti-range and
886 this assertion is an inequality (NE_EXPR), then we cannot
887 derive anything from the anti-range. For instance, if
888 LIMIT's range was ~[0, 0], the assertion 'VAR != LIMIT' does
889 not imply that VAR's range is [0, 0]. So, in the case of
890 anti-ranges, we just assert the inequality using LIMIT and
891 not its anti-range.
893 If LIMIT_VR is a range, we can only use it to build a new
894 anti-range if LIMIT_VR is a single-valued range. For
895 instance, if LIMIT_VR is [0, 1], the predicate
896 VAR != [0, 1] does not mean that VAR's range is ~[0, 1].
897 Rather, it means that for value 0 VAR should be ~[0, 0]
898 and for value 1, VAR should be ~[1, 1]. We cannot
899 represent these ranges.
901 The only situation in which we can build a valid
902 anti-range is when LIMIT_VR is a single-valued range
903 (i.e., LIMIT_VR->MIN == LIMIT_VR->MAX). In that case,
904 build the anti-range ~[LIMIT_VR->MIN, LIMIT_VR->MAX]. */
908 {
911 }
912 else
913 {
914 /* In any other case, we cannot use LIMIT's range to build a
915 valid anti-range. */
917 }
919 /* If MIN and MAX cover the whole range for their type, then
920 just use the original LIMIT. */
927 }
929 {
934 else
935 {
936 /* If LIMIT_VR is of the form [N1, N2], we need to build the
937 range [MIN, N2] for LE_EXPR and [MIN, N2 - 1] for
938 LT_EXPR. */
940 }
942 /* If the maximum value forces us to be out of bounds, simply punt.
943 It would be pointless to try and do anything more since this
944 all should be optimized away above us. */
947 else
948 {
949 /* For LT_EXPR, we create the range [MIN, MAX - 1]. */
951 {
954 }
957 }
958 }
960 {
965 else
966 {
967 /* If LIMIT_VR is of the form [N1, N2], we need to build the
968 range [N1, MAX] for GE_EXPR and [N1 + 1, MAX] for
969 GT_EXPR. */
971 }
973 /* If the minimum value forces us to be out of bounds, simply punt.
974 It would be pointless to try and do anything more since this
975 all should be optimized away above us. */
978 else
979 {
980 /* For GT_EXPR, we create the range [MIN + 1, MAX]. */
982 {
985 }
988 }
989 }
990 else
993 /* If VAR already had a known range, it may happen that the new
994 range we have computed and VAR's range are not compatible. For
995 instance,
997 if (p_5 == NULL)
998 p_6 = ASSERT_EXPR <p_5, p_5 == NULL>;
999 x_7 = p_6->fld;
1000 p_8 = ASSERT_EXPR <p_6, p_6 != NULL>;
1002 While the above comes from a faulty program, it will cause an ICE
1003 later because p_8 and p_6 will have incompatible ranges and at
1004 the same time will be considered equivalent. A similar situation
1005 would arise from
1007 if (i_5 > 10)
1008 i_6 = ASSERT_EXPR <i_5, i_5 > 10>;
1009 if (i_5 < 5)
1010 i_7 = ASSERT_EXPR <i_6, i_6 < 5>;
1012 Again i_6 and i_7 will have incompatible ranges. It would be
1013 pointless to try and do anything with i_7's range because
1014 anything dominated by 'if (i_5 < 5)' will be optimized away.
1015 Note, due to the wa in which simulation proceeds, the statement
1016 i_7 = ASSERT_EXPR <...> we would never be visited because the
1017 conditional 'if (i_5 < 5)' always evaluates to false. However,
1018 this extra check does not hurt and may protect against future
1019 changes to VRP that may get into a situation similar to the
1020 NULL pointer dereference example.
1022 Note that these compatibility tests are only needed when dealing
1023 with ranges or a mix of range and anti-range. If VAR_VR and VR_P
1024 are both anti-ranges, they will always be compatible, because two
1025 anti-ranges will always have a non-empty intersection. */
1029 /* We may need to make adjustments when VR_P and VAR_VR are numeric
1030 ranges or anti-ranges. */
1040 {
1041 /* If the two ranges have a non-empty intersection, we can
1042 refine the resulting range. Since the assert expression
1043 creates an equivalency and at the same time it asserts a
1044 predicate, we can take the intersection of the two ranges to
1045 get better precision. */
1047 {
1048 /* Use the larger of the two minimums. */
1051 else
1054 /* Use the smaller of the two maximums. */
1057 else
1061 }
1062 else
1063 {
1064 /* The two ranges do not intersect, set the new range to
1065 VARYING, because we will not be able to do anything
1066 meaningful with it. */
1068 }
1069 }
1072 {
1073 /* A range and an anti-range will cancel each other only if
1074 their ends are the same. For instance, in the example above,
1075 p_8's range ~[0, 0] and p_6's range [0, 0] are incompatible,
1076 so VR_P should be set to VR_VARYING. */
1080 else
1081 {
1084 /* We want to compute the logical AND of the two ranges;
1085 there are three cases to consider.
1088 1. The VR_ANTI_RANGE range is completely within the
1089 VR_RANGE and the endpoints of the ranges are
1090 different. In that case the resulting range
1091 should be whichever range is more precise.
1092 Typically that will be the VR_RANGE.
1094 2. The VR_ANTI_RANGE is completely disjoint from
1095 the VR_RANGE. In this case the resulting range
1096 should be the VR_RANGE.
1098 3. There is some overlap between the VR_ANTI_RANGE
1099 and the VR_RANGE.
1101 3a. If the high limit of the VR_ANTI_RANGE resides
1102 within the VR_RANGE, then the result is a new
1103 VR_RANGE starting at the high limit of the
1104 the VR_ANTI_RANGE + 1 and extending to the
1105 high limit of the original VR_RANGE.
1107 3b. If the low limit of the VR_ANTI_RANGE resides
1108 within the VR_RANGE, then the result is a new
1109 VR_RANGE starting at the low limit of the original
1110 VR_RANGE and extending to the low limit of the
1111 VR_ANTI_RANGE - 1. */
1113 {
1118 }
1119 else
1120 {
1125 }
1128 /* Case 1, VR_ANTI_RANGE completely within VR_RANGE,
1129 not including any endpoints. */
1132 {
1135 }
1136 /* Case 2, VR_ANTI_RANGE completely disjoint from
1137 VR_RANGE. */
1140 {
1143 }
1144 /* Case 3a, the anti-range extends into the low
1145 part of the real range. Thus creating a new
1146 low for the real range. */
1150 {
1152 anti_max,
1156 }
1157 /* Case 3b, the anti-range extends into the high
1158 part of the real range. Thus creating a new
1159 higher for the real range. */
1163 {
1165 anti_min,
1169 }
1170 }
1171 }
1173 /* Remove names from the equivalence set that have ranges
1174 incompatible with VR_P. */
1175 done:
1177 }
1180 /* Extract range information from SSA name VAR and store it in VR. If
1181 VAR has an interesting range, use it. Otherwise, create the
1182 range [VAR, VAR] and return it. This is useful in situations where
1183 we may have conditionals testing values of VARYING names. For
1184 instance,
1186 x_3 = y_5;
1187 if (x_3 > y_5)
1188 ...
1190 Even if y_5 is deemed VARYING, we can determine that x_3 > y_5 is
1191 always false. */
1193 static void
1195 {
1200 else
1204 }
1207 /* Wrapper around int_const_binop. If the operation overflows and we
1208 are not using wrapping arithmetic, then adjust the result to be
1209 -INF or +INF depending on CODE, VAL1 and VAL2. */
1213 {
1214 tree res;
1219 /* If we are not using wrapping arithmetic, operate symbolically
1220 on -INF and +INF. */
1224 {
1228 /* Ensure that res = val1 [+*] val2 >= val1
1229 or that res = val1 - val2 <= val1. */
1234 {
1236 }
1237 /* Checking for multiplication overflow is done by dividing the
1238 output of the multiplication by the first input of the
1239 multiplication. If the result of that division operation is
1240 not equal to the second input of the multiplication, then the
1241 multiplication overflowed. */
1243 {
1251 }
1254 {
1257 }
1259 }
1263 {
1264 /* If the operation overflowed but neither VAL1 nor VAL2 are
1265 overflown, return -INF or +INF depending on the operation
1266 and the combination of signs of the operands. */
1270 /* Notice that we only need to handle the restricted set of
1271 operations handled by extract_range_from_binary_expr.
1272 Among them, only multiplication, addition and subtraction
1273 can yield overflow without overflown operands because we
1274 are working with integral types only... except in the
1275 case VAL1 = -INF and VAL2 = -1 which overflows to +INF
1276 for division too. */
1278 /* For multiplication, the sign of the overflow is given
1279 by the comparison of the signs of the operands. */
1281 /* For addition, the operands must be of the same sign
1282 to yield an overflow. Its sign is therefore that
1283 of one of the operands, for example the first. */
1285 /* For subtraction, the operands must be of different
1286 signs to yield an overflow. Its sign is therefore
1287 that of the first operand or the opposite of that
1288 of the second operand. A first operand of 0 counts
1289 as positive here, for the corner case 0 - (-INF),
1290 which overflows, but must yield +INF. */
1292 /* For division, the only case is -INF / -1 = +INF. */
1299 else
1301 }
1304 }
1307 /* Extract range information from a binary expression EXPR based on
1308 the ranges of each of its operands and the expression code. */
1310 static void
1312 {
1320 /* Not all binary expressions can be applied to ranges in a
1321 meaningful way. Handle only arithmetic operations. */
1337 {
1340 }
1342 /* Get value ranges for each operand. For constant operands, create
1343 a new value range with the operand to simplify processing. */
1349 else
1357 else
1360 /* If either range is UNDEFINED, so is the result. */
1362 {
1365 }
1367 /* The type of the resulting value range defaults to VR0.TYPE. */
1370 /* Refuse to operate on VARYING ranges, ranges of different kinds
1371 and symbolic ranges. As an exception, we allow BIT_AND_EXPR
1372 because we may be able to derive a useful range even if one of
1373 the operands is VR_VARYING or symbolic range. TODO, we may be
1374 able to derive anti-ranges in some cases. */
1383 {
1386 }
1388 /* Now evaluate the expression to determine the new range. */
1392 {
1393 /* For pointer types, we are really only interested in asserting
1394 whether the expression evaluates to non-NULL. FIXME, we used
1395 to gcc_assert (code == PLUS_EXPR || code == MINUS_EXPR), but
1396 ivopts is generating expressions with pointer multiplication
1397 in them. */
1399 {
1404 else
1406 }
1407 else
1408 {
1409 /* Subtracting from a pointer, may yield 0, so just drop the
1410 resulting range to varying. */
1412 }
1415 }
1417 /* For integer ranges, apply the operation to each end of the
1418 range and see what we end up with. */
1423 {
1424 /* If one of the operands is zero, we know that the whole
1425 expression evaluates zero. */
1433 {
1436 }
1437 /* If one of the operands is one, we know that the whole
1438 expression evaluates one. */
1446 {
1449 }
1455 {
1456 /* Boolean expressions cannot be folded with int_const_binop. */
1459 }
1460 else
1461 {
1464 }
1465 }
1469 {
1470 /* If we have a PLUS_EXPR with two VR_ANTI_RANGEs, drop to
1471 VR_VARYING. It would take more effort to compute a precise
1472 range for such a case. For example, if we have op0 == 1 and
1473 op1 == -1 with their ranges both being ~[0,0], we would have
1474 op0 + op1 == 0, so we cannot claim that the sum is in ~[0,0].
1475 Note that we are guaranteed to have vr0.type == vr1.type at
1476 this point. */
1478 {
1481 }
1483 /* For operations that make the resulting range directly
1484 proportional to the original ranges, apply the operation to
1485 the same end of each range. */
1488 }
1495 {
1499 /* If we have an unsigned MULT_EXPR with two VR_ANTI_RANGEs,
1500 drop to VR_VARYING. It would take more effort to compute a
1501 precise range for such a case. For example, if we have
1502 op0 == 65536 and op1 == 65536 with their ranges both being
1503 ~[0,0] on a 32-bit machine, we would have op0 * op1 == 0, so
1504 we cannot claim that the product is in ~[0,0]. Note that we
1505 are guaranteed to have vr0.type == vr1.type at this
1506 point. */
1510 {
1513 }
1515 /* Multiplications and divisions are a bit tricky to handle,
1516 depending on the mix of signs we have in the two ranges, we
1517 need to operate on different values to get the minimum and
1518 maximum values for the new range. One approach is to figure
1519 out all the variations of range combinations and do the
1520 operations.
1522 However, this involves several calls to compare_values and it
1523 is pretty convoluted. It's simpler to do the 4 operations
1524 (MIN0 OP MIN1, MIN0 OP MAX1, MAX0 OP MIN1 and MAX0 OP MAX0 OP
1525 MAX1) and then figure the smallest and largest values to form
1526 the new range. */
1528 /* Divisions by zero result in a VARYING value. */
1531 {
1534 }
1536 /* Compute the 4 cross operations. */
1551 /* Set MIN to the minimum of VAL[i] and MAX to the maximum
1552 of VAL[i]. */
1556 {
1562 {
1564 {
1565 /* If we found an overflowed value, set MIN and MAX
1566 to it so that we set the resulting range to
1567 VARYING. */
1570 }
1577 }
1578 }
1579 }
1581 {
1582 /* If we have a MINUS_EXPR with two VR_ANTI_RANGEs, drop to
1583 VR_VARYING. It would take more effort to compute a precise
1584 range for such a case. For example, if we have op0 == 1 and
1585 op1 == 1 with their ranges both being ~[0,0], we would have
1586 op0 - op1 == 0, so we cannot claim that the difference is in
1587 ~[0,0]. Note that we are guaranteed to have
1588 vr0.type == vr1.type at this point. */
1590 {
1593 }
1595 /* For MINUS_EXPR, apply the operation to the opposite ends of
1596 each range. */
1599 }
1601 {
1606 {
1609 }
1614 {
1618 }
1619 else
1620 {
1623 }
1624 }
1625 else
1628 /* If either MIN or MAX overflowed, then set the resulting range to
1629 VARYING. */
1632 {
1635 }
1639 {
1640 /* If the new range has its limits swapped around (MIN > MAX),
1641 then the operation caused one of them to wrap around, mark
1642 the new range VARYING. */
1644 }
1645 else
1647 }
1650 /* Extract range information from a unary expression EXPR based on
1651 the range of its operand and the expression code. */
1653 static void
1655 {
1661 /* Refuse to operate on certain unary expressions for which we
1662 cannot easily determine a resulting range. */
1671 {
1674 }
1676 /* Get value ranges for the operand. For constant operands, create
1677 a new value range with the operand to simplify processing. */
1683 else
1686 /* If VR0 is UNDEFINED, so is the result. */
1688 {
1691 }
1693 /* Refuse to operate on symbolic ranges, or if neither operand is
1694 a pointer or integral type. */
1699 {
1702 }
1704 /* If the expression involves pointers, we are only interested in
1705 determining if it evaluates to NULL [0, 0] or non-NULL (~[0, 0]). */
1707 {
1712 else
1716 }
1718 /* Handle unary expressions on integer ranges. */
1720 {
1724 /* If VR0 represents a simple range, then try to convert
1725 the min and max values for the range to the same type
1726 as OUTER_TYPE. If the results compare equal to VR0's
1727 min and max values and the new min is still less than
1728 or equal to the new max, then we can safely use the newly
1729 computed range for EXPR. This allows us to compute
1730 accurate ranges through many casts. */
1734 {
1737 /* Convert the input operand min/max to OUTER_TYPE. If
1738 the input has no range information, then use the min/max
1739 for the input's type. */
1741 {
1744 }
1745 else
1746 {
1749 }
1754 /* Verify the new min/max values are gimple values and
1755 that they compare equal to the original input's
1756 min/max values. */
1763 {
1766 }
1767 }
1769 /* When converting types of different sizes, set the result to
1770 VARYING. Things like sign extensions and precision loss may
1771 change the range. For instance, if x_3 is of type 'long long
1772 int' and 'y_5 = (unsigned short) x_3', if x_3 is ~[0, 0], it
1773 is impossible to know at compile time whether y_5 will be
1774 ~[0, 0]. */
1777 {
1780 }
1781 }
1783 /* Conversion of a VR_VARYING value to a wider type can result
1784 in a usable range. So wait until after we've handled conversions
1785 before dropping the result to VR_VARYING if we had a source
1786 operand that is VR_VARYING. */
1788 {
1791 }
1793 /* Apply the operation to each end of the range and see what we end
1794 up with. */
1797 {
1798 /* NEGATE_EXPR flips the range around. We need to treat
1799 TYPE_MIN_VALUE specially dependent on wrapping, range type
1800 and if it was used as minimum or maximum value:
1801 -~[MIN, MIN] == ~[MIN, MIN]
1802 -[MIN, 0] == [0, MAX] for -fno-wrapv
1803 -[MIN, 0] == [0, MIN] for -fwrapv (will be set to varying later) */
1814 }
1817 {
1819 {
1822 }
1823 else
1824 {
1827 else
1830 }
1831 }
1834 {
1835 /* -TYPE_MIN_VALUE = TYPE_MIN_VALUE with flag_wrapv so we can't get a
1836 useful range. */
1843 {
1846 }
1848 /* ABS_EXPR may flip the range around, if the original range
1849 included negative values. */
1858 /* If a VR_ANTI_RANGEs contains zero, then we have
1859 ~[-INF, min(MIN, MAX)]. */
1861 {
1863 {
1866 /* Take the lower of the two values. */
1870 /* Create ~[-INF, min (abs(MIN), abs(MAX))]
1871 or ~[-INF + 1, min (abs(MIN), abs(MAX))] when
1872 flag_wrapv is set and the original anti-range doesn't include
1873 TYPE_MIN_VALUE, remember -TYPE_MIN_VALUE = TYPE_MIN_VALUE. */
1876 type_min_value,
1879 }
1880 else
1881 {
1882 /* All else has failed, so create the range [0, INF], even for
1883 flag_wrapv since TYPE_MIN_VALUE is in the original
1884 anti-range. */
1888 }
1889 }
1891 /* If the range contains zero then we know that the minimum value in the
1892 range will be zero. */
1894 {
1898 }
1899 else
1900 {
1901 /* If the range was reversed, swap MIN and MAX. */
1903 {
1907 }
1908 }
1909 }
1910 else
1911 {
1912 /* Otherwise, operate on each end of the range. */
1915 }
1919 {
1920 /* If the new range has its limits swapped around (MIN > MAX),
1921 then the operation caused one of them to wrap around, mark
1922 the new range VARYING. */
1924 }
1925 else
1927 }
1930 /* Extract range information from a comparison expression EXPR based
1931 on the range of its operand and the expression code. */
1933 static void
1935 {
1938 {
1939 /* Since this expression was found on the RHS of an assignment,
1940 its type may be different from _Bool. Convert VAL to EXPR's
1941 type. */
1944 }
1945 else
1947 }
1950 /* Try to compute a useful range out of expression EXPR and store it
1951 in *VR. */
1953 static void
1955 {
1975 else
1978 /* If we got a varying range from the tests above, try a final
1979 time to derive a nonnegative or nonzero range. This time
1980 relying primarily on generic routines in fold in conjunction
1981 with range data. */
1983 {
1989 }
1990 }
1992 /* Given a range VR, a LOOP and a variable VAR, determine whether it
1993 would be profitable to adjust VR using scalar evolution information
1994 for VAR. If so, update VR with the new limits. */
1996 static void
1998 tree var)
1999 {
2003 /* TODO. Don't adjust anti-ranges. An anti-range may provide
2004 better opportunities than a regular range, but I'm not sure. */
2015 /* If STEP is symbolic, we can't know whether INIT will be the
2016 minimum or maximum value in the range. Also, unless INIT is
2017 a simple expression, compare_values and possibly other functions
2018 in tree-vrp won't be able to handle it. */
2026 or decreases, ... */
2027 dir == EV_DIR_UNKNOWN
2028 /* ... or if it may wrap. */
2036 {
2037 /* For VARYING or UNDEFINED ranges, just about anything we get
2038 from scalar evolutions should be better. */
2044 else
2047 /* If we would create an invalid range, then just assume we
2048 know absolutely nothing. This may be over-conservative,
2049 but it's clearly safe. */
2054 }
2056 {
2061 {
2062 /* INIT is the maximum value. If INIT is lower than VR->MAX
2063 but no smaller than VR->MIN, set VR->MAX to INIT. */
2065 {
2068 /* If we just created an invalid range with the minimum
2069 greater than the maximum, take the minimum all the
2070 way to -INF. */
2073 }
2074 }
2075 else
2076 {
2077 /* If INIT is bigger than VR->MIN, set VR->MIN to INIT. */
2079 {
2082 /* If we just created an invalid range with the minimum
2083 greater than the maximum, take the maximum all the
2084 way to +INF. */
2087 }
2088 }
2091 }
2092 }
2095 /* Given two numeric value ranges VR0, VR1 and a comparison code COMP:
2097 - Return BOOLEAN_TRUE_NODE if VR0 COMP VR1 always returns true for
2098 all the values in the ranges.
2100 - Return BOOLEAN_FALSE_NODE if the comparison always returns false.
2102 - Return NULL_TREE if it is not always possible to determine the
2103 value of the comparison. */
2106 static tree
2108 {
2109 /* VARYING or UNDEFINED ranges cannot be compared. */
2116 /* Anti-ranges need to be handled separately. */
2118 {
2119 /* If both are anti-ranges, then we cannot compute any
2120 comparison. */
2124 /* These comparisons are never statically computable. */
2131 /* Equality can be computed only between a range and an
2132 anti-range. ~[VAL1, VAL2] == [VAL1, VAL2] is always false. */
2134 {
2135 /* To simplify processing, make VR0 the anti-range. */
2139 }
2148 }
2150 /* Simplify processing. If COMP is GT_EXPR or GE_EXPR, switch the
2151 operands around and change the comparison code. */
2153 {
2159 }
2162 {
2163 /* Equality may only be computed if both ranges represent
2164 exactly one value. */
2167 {
2174 }
2175 /* If [V0_MIN, V1_MAX] < [V1_MIN, V1_MAX] then V0 != V1. */
2181 }
2183 {
2186 /* If VR0 is completely to the left or completely to the right
2187 of VR1, they are always different. Notice that we need to
2188 make sure that both comparisons yield similar results to
2189 avoid comparing values that cannot be compared at
2190 compile-time. */
2196 /* If VR0 and VR1 represent a single value and are identical,
2197 return false. */
2204 /* Otherwise, they may or may not be different. */
2205 else
2207 }
2209 {
2212 /* If VR0 is to the left of VR1, return true. */
2218 /* If VR0 is to the right of VR1, return false. */
2224 /* Otherwise, we don't know. */
2226 }
2229 }
2232 /* Given a value range VR, a value VAL and a comparison code COMP, return
2233 BOOLEAN_TRUE_NODE if VR COMP VAL always returns true for all the
2234 values in VR. Return BOOLEAN_FALSE_NODE if the comparison
2235 always returns false. Return NULL_TREE if it is not always
2236 possible to determine the value of the comparison. */
2238 static tree
2240 {
2244 /* Anti-ranges need to be handled separately. */
2246 {
2247 /* For anti-ranges, the only predicates that we can compute at
2248 compile time are equality and inequality. */
2255 /* ~[VAL_1, VAL_2] OP VAL is known if VAL_1 <= VAL <= VAL_2. */
2260 }
2263 {
2264 /* EQ_EXPR may only be computed if VR represents exactly
2265 one value. */
2267 {
2273 }
2279 }
2281 {
2282 /* If VAL is not inside VR, then they are always different. */
2287 /* If VR represents exactly one value equal to VAL, then return
2288 false. */
2293 /* Otherwise, they may or may not be different. */
2295 }
2297 {
2300 /* If VR is to the left of VAL, return true. */
2306 /* If VR is to the right of VAL, return false. */
2312 /* Otherwise, we don't know. */
2314 }
2316 {
2319 /* If VR is to the right of VAL, return true. */
2325 /* If VR is to the left of VAL, return false. */
2331 /* Otherwise, we don't know. */
2333 }
2336 }
2339 /* Debugging dumps. */
2349 /* Dump value range VR to FILE. */
2351 void
2353 {
2359 {
2368 else
2376 else
2382 {
2383 bitmap_iterator bi;
2389 {
2392 c++;
2393 }
2396 }
2397 }
2400 else
2402 }
2405 /* Dump value range VR to stderr. */
2407 void
2409 {
2411 }
2414 /* Dump value ranges of all SSA_NAMEs to FILE. */
2416 void
2418 {
2422 {
2424 {
2429 }
2430 }
2433 }
2436 /* Dump all value ranges to stderr. */
2438 void
2440 {
2442 }
2445 /* Given a COND_EXPR COND of the form 'V OP W', and an SSA name V,
2446 create a new SSA name N and return the assertion assignment
2447 'V = ASSERT_EXPR <V, V OP W>'. */
2449 static tree
2451 {
2458 {
2461 }
2463 {
2464 /* Given !V, build the assignment N = false. */
2468 }
2470 {
2471 /* Given V, build the assignment N = true. */
2474 }
2475 else
2480 /* The new ASSERT_EXPR, creates a new SSA name that replaces the
2481 operand of the ASSERT_EXPR. Register the new name and the old one
2482 in the replacement table so that we can fix the SSA web after
2483 adding all the ASSERT_EXPRs. */
2487 }
2490 /* Return false if EXPR is a predicate expression involving floating
2491 point values. */
2495 {
2498 }
2501 /* If the range of values taken by OP can be inferred after STMT executes,
2502 return the comparison code (COMP_CODE_P) and value (VAL_P) that
2503 describes the inferred range. Return true if a range could be
2504 inferred. */
2506 static bool
2508 {
2512 /* Do not attempt to infer anything in names that flow through
2513 abnormal edges. */
2517 /* Similarly, don't infer anything from statements that may throw
2518 exceptions. */
2522 /* If STMT is the last statement of a basic block with no
2523 successors, there is no point inferring anything about any of its
2524 operands. We would not be able to find a proper insertion point
2525 for the assertion, anyway. */
2529 /* We can only assume that a pointer dereference will yield
2530 non-NULL if -fdelete-null-pointer-checks is enabled. */
2532 {
2538 {
2542 }
2543 }
2546 }
2554 /* Dump all the registered assertions for NAME to FILE. */
2556 void
2558 {
2559 assert_locus_t loc;
2567 {
2572 {
2576 }
2583 }
2586 }
2589 /* Dump all the registered assertions for NAME to stderr. */
2591 void
2593 {
2595 }
2598 /* Dump all the registered assertions for all the names to FILE. */
2600 void
2602 {
2604 bitmap_iterator bi;
2610 }
2613 /* Dump all the registered assertions for all the names to stderr. */
2615 void
2617 {
2619 }
2622 /* If NAME doesn't have an ASSERT_EXPR registered for asserting
2623 'NAME COMP_CODE VAL' at a location that dominates block BB or
2624 E->DEST, then register this location as a possible insertion point
2625 for ASSERT_EXPR <NAME, NAME COMP_CODE VAL>.
2627 BB, E and SI provide the exact insertion point for the new
2628 ASSERT_EXPR. If BB is NULL, then the ASSERT_EXPR is to be inserted
2629 on edge E. Otherwise, if E is NULL, the ASSERT_EXPR is inserted on
2630 BB. If SI points to a COND_EXPR or a SWITCH_EXPR statement, then E
2631 must not be NULL. */
2633 static void
2636 tree val,
2637 basic_block bb,
2638 edge e,
2639 block_stmt_iterator si)
2640 {
2643 basic_block dest_bb;
2645 #if defined ENABLE_CHECKING
2651 #endif
2653 /* The new assertion A will be inserted at BB or E. We need to
2654 determine if the new location is dominated by a previously
2655 registered location for A. If we are doing an edge insertion,
2656 assume that A will be inserted at E->DEST. Note that this is not
2657 necessarily true.
2659 If E is a critical edge, it will be split. But even if E is
2660 split, the new block will dominate the same set of blocks that
2661 E->DEST dominates.
2663 The reverse, however, is not true, blocks dominated by E->DEST
2664 will not be dominated by the new block created to split E. So,
2665 if the insertion location is on a critical edge, we will not use
2666 the new location to move another assertion previously registered
2667 at a block dominated by E->DEST. */
2670 /* If NAME already has an ASSERT_EXPR registered for COMP_CODE and
2671 VAL at a block dominating DEST_BB, then we don't need to insert a new
2672 one. Similarly, if the same assertion already exists at a block
2673 dominated by DEST_BB and the new location is not on a critical
2674 edge, then update the existing location for the assertion (i.e.,
2675 move the assertion up in the dominance tree).
2677 Note, this is implemented as a simple linked list because there
2678 should not be more than a handful of assertions registered per
2679 name. If this becomes a performance problem, a table hashed by
2680 COMP_CODE and VAL could be implemented. */
2685 {
2689 {
2690 /* If the assertion NAME COMP_CODE VAL has already been
2691 registered at a basic block that dominates DEST_BB, then
2692 we don't need to insert the same assertion again. Note
2693 that we don't check strict dominance here to avoid
2694 replicating the same assertion inside the same basic
2695 block more than once (e.g., when a pointer is
2696 dereferenced several times inside a block).
2698 An exception to this rule are edge insertions. If the
2699 new assertion is to be inserted on edge E, then it will
2700 dominate all the other insertions that we may want to
2701 insert in DEST_BB. So, if we are doing an edge
2702 insertion, don't do this dominance check. */
2707 /* Otherwise, if E is not a critical edge and DEST_BB
2708 dominates the existing location for the assertion, move
2709 the assertion up in the dominance tree by updating its
2710 location information. */
2713 {
2718 }
2719 }
2721 /* Update the last node of the list and move to the next one. */
2724 }
2726 /* If we didn't find an assertion already registered for
2727 NAME COMP_CODE VAL, add a new one at the end of the list of
2728 assertions associated with NAME. */
2739 else
2743 }
2746 /* Try to register an edge assertion for SSA name NAME on edge E for
2747 the conditional jump pointed to by SI. Return true if an assertion
2748 for NAME could be registered. */
2750 static bool
2752 {
2758 /* Do not attempt to infer anything in names that flow through
2759 abnormal edges. */
2763 /* If NAME was not found in the sub-graph reachable from E, then
2764 there's nothing to do. */
2768 /* We found a use of NAME in the sub-graph rooted at E->DEST.
2769 Register an assertion for NAME according to the value that NAME
2770 takes on edge E. */
2772 {
2773 /* If BB ends in a COND_EXPR then NAME then we should insert
2774 the original predicate on EDGE_TRUE_VALUE and the
2775 opposite predicate on EDGE_FALSE_VALUE. */
2779 /* Predicates may be a single SSA name or NAME OP VAL. */
2781 {
2782 /* If the predicate is a name, it must be NAME, in which
2783 case we create the predicate NAME == true or
2784 NAME == false accordingly. */
2787 }
2788 else
2789 {
2790 /* Otherwise, we have a comparison of the form NAME COMP VAL
2791 or VAL COMP NAME. */
2793 {
2794 /* If the predicate is of the form VAL COMP NAME, flip
2795 COMP around because we need to register NAME as the
2796 first operand in the predicate. */
2799 }
2800 else
2801 {
2802 /* The comparison is of the form NAME COMP VAL, so the
2803 comparison code remains unchanged. */
2806 }
2808 /* If we are inserting the assertion on the ELSE edge, we
2809 need to invert the sign comparison. */
2813 /* Do not register always-false predicates. FIXME, this
2814 works around a limitation in fold() when dealing with
2815 enumerations. Given 'enum { N1, N2 } x;', fold will not
2816 fold 'if (x > N2)' to 'if (0)'. */
2820 {
2829 }
2830 }
2831 }
2832 else
2833 {
2834 /* FIXME. Handle SWITCH_EXPR. */
2836 }
2840 }
2845 /* Determine whether the outgoing edges of BB should receive an
2846 ASSERT_EXPR for each of the operands of BB's last statement. The
2847 last statement of BB must be a COND_EXPR or a SWITCH_EXPR.
2849 If any of the sub-graphs rooted at BB have an interesting use of
2850 the predicate operands, an assert location node is added to the
2851 list of assertions for the corresponding operands. */
2853 static bool
2855 {
2857 block_stmt_iterator last_si;
2859 edge_iterator ei;
2860 edge e;
2861 ssa_op_iter iter;
2867 /* Look for uses of the operands in each of the sub-graphs
2868 rooted at BB. We need to check each of the outgoing edges
2869 separately, so that we know what kind of ASSERT_EXPR to
2870 insert. */
2872 {
2876 /* Remove the COND_EXPR operands from the FOUND_IN_SUBGRAPH bitmap.
2877 Otherwise, when we finish traversing each of the sub-graphs, we
2878 won't know whether the variables were found in the sub-graphs or
2879 if they had been found in a block upstream from BB.
2881 This is actually a bad idea is some cases, particularly jump
2882 threading. Consider a CFG like the following:
2884 0
2885 /|
2886 1 |
2887 \|
2888 2
2889 / \
2890 3 4
2892 Assume that one or more operands in the conditional at the
2893 end of block 0 are used in a conditional in block 2, but not
2894 anywhere in block 1. In this case we will not insert any
2895 assert statements in block 1, which may cause us to miss
2896 opportunities to optimize, particularly for jump threading. */
2900 /* Traverse the strictly dominated sub-graph rooted at E->DEST
2901 to determine if any of the operands in the conditional
2902 predicate are used. */
2906 /* Register the necessary assertions for each operand in the
2907 conditional predicate. */
2910 }
2912 /* Finally, indicate that we have found the operands in the
2913 conditional. */
2918 }
2921 /* Traverse all the statements in block BB looking for statements that
2922 may generate useful assertions for the SSA names in their operand.
2923 If a statement produces a useful assertion A for name N_i, then the
2924 list of assertions already generated for N_i is scanned to
2925 determine if A is actually needed.
2927 If N_i already had the assertion A at a location dominating the
2928 current location, then nothing needs to be done. Otherwise, the
2929 new location for A is recorded instead.
2931 1- For every statement S in BB, all the variables used by S are
2932 added to bitmap FOUND_IN_SUBGRAPH.
2934 2- If statement S uses an operand N in a way that exposes a known
2935 value range for N, then if N was not already generated by an
2936 ASSERT_EXPR, create a new assert location for N. For instance,
2937 if N is a pointer and the statement dereferences it, we can
2938 assume that N is not NULL.
2940 3- COND_EXPRs are a special case of #2. We can derive range
2941 information from the predicate but need to insert different
2942 ASSERT_EXPRs for each of the sub-graphs rooted at the
2943 conditional block. If the last statement of BB is a conditional
2944 expression of the form 'X op Y', then
2946 a) Remove X and Y from the set FOUND_IN_SUBGRAPH.
2948 b) If the conditional is the only entry point to the sub-graph
2949 corresponding to the THEN_CLAUSE, recurse into it. On
2950 return, if X and/or Y are marked in FOUND_IN_SUBGRAPH, then
2951 an ASSERT_EXPR is added for the corresponding variable.
2953 c) Repeat step (b) on the ELSE_CLAUSE.
2955 d) Mark X and Y in FOUND_IN_SUBGRAPH.
2957 For instance,
2959 if (a == 9)
2960 b = a;
2961 else
2962 b = c + 1;
2964 In this case, an assertion on the THEN clause is useful to
2965 determine that 'a' is always 9 on that edge. However, an assertion
2966 on the ELSE clause would be unnecessary.
2968 4- If BB does not end in a conditional expression, then we recurse
2969 into BB's dominator children.
2971 At the end of the recursive traversal, every SSA name will have a
2972 list of locations where ASSERT_EXPRs should be added. When a new
2973 location for name N is found, it is registered by calling
2974 register_new_assert_for. That function keeps track of all the
2975 registered assertions to prevent adding unnecessary assertions.
2976 For instance, if a pointer P_4 is dereferenced more than once in a
2977 dominator tree, only the location dominating all the dereference of
2978 P_4 will receive an ASSERT_EXPR.
2980 If this function returns true, then it means that there are names
2981 for which we need to generate ASSERT_EXPRs. Those assertions are
2982 inserted by process_assert_insertions.
2984 TODO. Handle SWITCH_EXPR. */
2986 static bool
2988 {
2989 block_stmt_iterator si;
2992 basic_block son;
3001 /* Traverse all PHI nodes in BB marking used operands. */
3003 {
3004 use_operand_p arg_p;
3005 ssa_op_iter i;
3008 {
3011 {
3014 }
3015 }
3016 }
3018 /* Traverse all the statements in BB marking used names and looking
3019 for statements that may infer assertions for their used operands. */
3022 {
3024 ssa_op_iter i;
3028 /* See if we can derive an assertion for any of STMT's operands. */
3030 {
3031 tree value;
3034 /* Mark OP in bitmap FOUND_IN_SUBGRAPH. If STMT is inside
3035 the sub-graph of a conditional block, when we return from
3036 this recursive walk, our parent will use the
3037 FOUND_IN_SUBGRAPH bitset to determine if one of the
3038 operands it was looking for was present in the sub-graph. */
3041 /* If OP is used in such a way that we can infer a value
3042 range for it, and we don't find a previous assertion for
3043 it, create a new assertion location node for OP. */
3045 {
3046 /* If we are able to infer a nonzero value range for OP,
3047 then walk backwards through the use-def chain to see if OP
3048 was set via a typecast.
3050 If so, then we can also infer a nonzero value range
3051 for the operand of the NOP_EXPR. */
3053 {
3061 {
3065 /* Note we want to register the assert for the
3066 operand of the NOP_EXPR after SI, not after the
3067 conversion. */
3069 {
3073 }
3074 }
3075 }
3077 /* If OP is used only once, namely in this STMT, don't
3078 bother creating an ASSERT_EXPR for it. Such an
3079 ASSERT_EXPR would do nothing but increase compile time. */
3081 {
3084 }
3085 }
3086 }
3088 /* Remember the last statement of the block. */
3090 }
3092 /* If BB's last statement is a conditional expression
3093 involving integer operands, recurse into each of the sub-graphs
3094 rooted at BB to determine if we need to add ASSERT_EXPRs. */
3101 /* Recurse into the dominator children of BB. */
3103 son;
3108 }
3111 /* Create an ASSERT_EXPR for NAME and insert it in the location
3112 indicated by LOC. Return true if we made any edge insertions. */
3114 static bool
3116 {
3117 /* Build the comparison expression NAME_i COMP_CODE VAL. */
3119 edge_iterator ei;
3120 edge e;
3126 {
3127 /* We have been asked to insert the assertion on an edge. This
3128 is used only by COND_EXPR and SWITCH_EXPR assertions. */
3129 #if defined ENABLE_CHECKING
3132 #endif
3136 }
3138 /* Otherwise, we can insert right after LOC->SI iff the
3139 statement must not be the last statement in the block. */
3142 {
3145 }
3147 /* If STMT must be the last statement in BB, we can only insert new
3148 assertions on the non-abnormal edge out of BB. Note that since
3149 STMT is not control flow, there may only be one non-abnormal edge
3150 out of BB. */
3153 {
3156 }
3159 }
3162 /* Process all the insertions registered for every name N_i registered
3163 in NEED_ASSERT_FOR. The list of assertions to be inserted are
3164 found in ASSERTS_FOR[i]. */
3166 static void
3168 {
3170 bitmap_iterator bi;
3178 {
3183 {
3188 num_asserts++;
3189 }
3190 }
3197 num_asserts);
3198 }
3201 /* Traverse the flowgraph looking for conditional jumps to insert range
3202 expressions. These range expressions are meant to provide information
3203 to optimizations that need to reason in terms of value ranges. They
3204 will not be expanded into RTL. For instance, given:
3206 x = ...
3207 y = ...
3208 if (x < y)
3209 y = x - 2;
3210 else
3211 x = y + 3;
3213 this pass will transform the code into:
3215 x = ...
3216 y = ...
3217 if (x < y)
3218 {
3219 x = ASSERT_EXPR <x, x < y>
3220 y = x - 2
3221 }
3222 else
3223 {
3224 y = ASSERT_EXPR <y, x <= y>
3225 x = y + 3
3226 }
3228 The idea is that once copy and constant propagation have run, other
3229 optimizations will be able to determine what ranges of values can 'x'
3230 take in different paths of the code, simply by checking the reaching
3231 definition of 'x'. */
3233 static void
3235 {
3236 edge e;
3237 edge_iterator ei;
3258 {
3261 }
3264 {
3267 }
3272 }
3275 /* Convert range assertion expressions into the implied copies and
3276 copy propagate away the copies. Doing the trivial copy propagation
3277 here avoids the need to run the full copy propagation pass after
3278 VRP.
3280 FIXME, this will eventually lead to copy propagation removing the
3281 names that had useful range information attached to them. For
3282 instance, if we had the assertion N_i = ASSERT_EXPR <N_j, N_j > 3>,
3283 then N_i will have the range [3, +INF].
3285 However, by converting the assertion into the implied copy
3286 operation N_i = N_j, we will then copy-propagate N_j into the uses
3287 of N_i and lose the range information. We may want to hold on to
3288 ASSERT_EXPRs a little while longer as the ranges could be used in
3289 things like jump threading.
3291 The problem with keeping ASSERT_EXPRs around is that passes after
3292 VRP need to handle them appropriately.
3294 Another approach would be to make the range information a first
3295 class property of the SSA_NAME so that it can be queried from
3296 any pass. This is made somewhat more complex by the need for
3297 multiple ranges to be associated with one SSA_NAME. */
3299 static void
3301 {
3302 basic_block bb;
3303 block_stmt_iterator si;
3305 /* Note that the BSI iterator bump happens at the bottom of the
3306 loop and no bump is necessary if we're removing the statement
3307 referenced by the current BSI. */
3310 {
3312 tree use_stmt;
3316 {
3319 use_operand_p use_p;
3320 imm_use_iterator iter;
3324 /* Propagate the RHS into every use of the LHS. */
3328 {
3331 }
3333 /* And finally, remove the copy, it is not needed. */
3335 }
3336 else
3338 }
3341 }
3344 /* Return true if STMT is interesting for VRP. */
3346 static bool
3348 {
3355 {
3359 /* In general, assignments with virtual operands are not useful
3360 for deriving ranges, with the obvious exception of calls to
3361 builtin functions. */
3371 }
3376 }
3379 /* Initialize local data structures for VRP. */
3381 static void
3383 {
3384 basic_block bb;
3390 {
3391 block_stmt_iterator si;
3392 tree phi;
3395 {
3397 {
3401 }
3402 else
3404 }
3407 {
3411 {
3412 ssa_op_iter i;
3413 tree def;
3417 }
3418 else
3419 {
3421 }
3422 }
3423 }
3424 }
3427 /* Visit assignment STMT. If it produces an interesting range, record
3428 the SSA name in *OUTPUT_P. */
3430 static enum ssa_prop_result
3432 {
3434 ssa_op_iter iter;
3439 /* We only keep track of ranges in integral and pointer types. */
3442 /* It is valid to have NULL MIN/MAX values on a type. See
3443 build_range_type. */
3447 {
3453 /* If STMT is inside a loop, we may be able to know something
3454 else about the range of LHS by examining scalar evolution
3455 information. */
3460 {
3464 {
3470 }
3476 }
3479 }
3481 /* Every other statement produces no useful ranges. */
3486 }
3489 /* Compare all the value ranges for names equivalent to VAR with VAL
3490 using comparison code COMP. Return the same value returned by
3491 compare_range_with_value. */
3493 static tree
3495 {
3496 bitmap_iterator bi;
3498 bitmap e;
3503 /* Get the set of equivalences for VAR. */
3506 /* Add VAR to its own set of equivalences so that VAR's value range
3507 is processed by this loop (otherwise, we would have to replicate
3508 the body of the loop just to check VAR's value range). */
3512 {
3515 /* If name N_i does not have a valid range, use N_i as its own
3516 range. This allows us to compare against names that may
3517 have N_i in their ranges. */
3519 {
3523 }
3527 {
3528 /* All the ranges should compare the same against VAL. */
3531 }
3532 }
3534 /* Remove VAR from its own equivalence set. */
3540 /* We couldn't find a non-NULL value for the predicate. */
3542 }
3545 /* Given a comparison code COMP and names N1 and N2, compare all the
3546 ranges equivalent to N1 against all the ranges equivalent to N2
3547 to determine the value of N1 COMP N2. Return the same value
3548 returned by compare_ranges. */
3550 static tree
3552 {
3558 /* Compare the ranges of every name equivalent to N1 against the
3559 ranges of every name equivalent to N2. */
3563 /* Add N1 and N2 to their own set of equivalences to avoid
3564 duplicating the body of the loop just to check N1 and N2
3565 ranges. */
3569 /* If the equivalence sets have a common intersection, then the two
3570 names can be compared without checking their ranges. */
3572 {
3577 ? boolean_true_node
3579 }
3581 /* Otherwise, compare all the equivalent ranges. First, add N1 and
3582 N2 to their own set of equivalences to avoid duplicating the body
3583 of the loop just to check N1 and N2 ranges. */
3585 {
3588 /* If the range is VARYING or UNDEFINED, use the name itself. */
3590 {
3594 }
3598 {
3602 {
3606 }
3610 {
3611 /* All the ranges in the equivalent sets should compare
3612 the same. */
3615 }
3616 }
3619 {
3623 }
3624 }
3626 /* None of the equivalent ranges are useful in computing this
3627 comparison. */
3631 }
3634 /* Given a conditional predicate COND, try to determine if COND yields
3635 true or false based on the value ranges of its operands. Return
3636 BOOLEAN_TRUE_NODE if the conditional always evaluates to true,
3637 BOOLEAN_FALSE_NODE if the conditional always evaluates to false, and,
3638 NULL if the conditional cannot be evaluated at compile time.
3640 If USE_EQUIV_P is true, the ranges of all the names equivalent with
3641 the operands in COND are used when trying to compute its value.
3642 This is only used during final substitution. During propagation,
3643 we only check the range of each variable and not its equivalents. */
3645 tree
3647 {
3652 {
3654 tree retval;
3658 else
3659 {
3662 }
3664 /* If COND has a known boolean range, return it. */
3668 /* Otherwise, if COND has a symbolic range of exactly one value,
3669 return it. */
3673 }
3674 else
3675 {
3679 /* We only deal with integral and pointer types. */
3685 {
3693 }
3694 else
3695 {
3708 }
3709 }
3711 /* Anything else cannot be computed statically. */
3713 }
3716 /* Visit conditional statement STMT. If we can determine which edge
3717 will be taken out of STMT's basic block, record it in
3718 *TAKEN_EDGE_P and return SSA_PROP_INTERESTING. Otherwise, return
3719 SSA_PROP_VARYING. */
3721 static enum ssa_prop_result
3723 {
3728 /* FIXME. Handle SWITCH_EXPRs. But first, the assert pass needs to
3729 add ASSERT_EXPRs for them. */
3736 {
3737 tree use;
3738 ssa_op_iter i;
3745 {
3750 }
3753 }
3755 /* Compute the value of the predicate COND by checking the known
3756 ranges of each of its operands.
3758 Note that we cannot evaluate all the equivalent ranges here
3759 because those ranges may not yet be final and with the current
3760 propagation strategy, we cannot determine when the value ranges
3761 of the names in the equivalence set have changed.
3763 For instance, given the following code fragment
3765 i_5 = PHI <8, i_13>
3766 ...
3767 i_14 = ASSERT_EXPR <i_5, i_5 != 0>
3768 if (i_14 == 1)
3769 ...
3771 Assume that on the first visit to i_14, i_5 has the temporary
3772 range [8, 8] because the second argument to the PHI function is
3773 not yet executable. We derive the range ~[0, 0] for i_14 and the
3774 equivalence set { i_5 }. So, when we visit 'if (i_14 == 1)' for
3775 the first time, since i_14 is equivalent to the range [8, 8], we
3776 determine that the predicate is always false.
3778 On the next round of propagation, i_13 is determined to be
3779 VARYING, which causes i_5 to drop down to VARYING. So, another
3780 visit to i_14 is scheduled. In this second visit, we compute the
3781 exact same range and equivalence set for i_14, namely ~[0, 0] and
3782 { i_5 }. But we did not have the previous range for i_5
3783 registered, so vrp_visit_assignment thinks that the range for
3784 i_14 has not changed. Therefore, the predicate 'if (i_14 == 1)'
3785 is not visited again, which stops propagation from visiting
3786 statements in the THEN clause of that if().
3788 To properly fix this we would need to keep the previous range
3789 value for the names in the equivalence set. This way we would've
3790 discovered that from one visit to the other i_5 changed from
3791 range [8, 8] to VR_VARYING.
3793 However, fixing this apparent limitation may not be worth the
3794 additional checking. Testing on several code bases (GCC, DLV,
3795 MICO, TRAMP3D and SPEC2000) showed that doing this results in
3796 4 more predicates folded in SPEC. */
3802 {
3806 else
3808 }
3811 }
3814 /* Evaluate statement STMT. If the statement produces a useful range,
3815 return SSA_PROP_INTERESTING and record the SSA name with the
3816 interesting range into *OUTPUT_P.
3818 If STMT is a conditional branch and we can determine its truth
3819 value, the taken edge is recorded in *TAKEN_EDGE_P.
3821 If STMT produces a varying value, return SSA_PROP_VARYING. */
3823 static enum ssa_prop_result
3825 {
3826 tree def;
3827 ssa_op_iter iter;
3828 stmt_ann_t ann;
3831 {
3835 }
3839 {
3842 /* In general, assignments with virtual operands are not useful
3843 for deriving ranges, with the obvious exception of calls to
3844 builtin functions. */
3851 }
3855 /* All other statements produce nothing of interest for VRP, so mark
3856 their outputs varying and prevent further simulation. */
3861 }
3864 /* Meet operation for value ranges. Given two value ranges VR0 and
3865 VR1, store in VR0 the result of meeting VR0 and VR1.
3867 The meeting rules are as follows:
3869 1- If VR0 and VR1 have an empty intersection, set VR0 to VR_VARYING.
3871 2- If VR0 and VR1 have a non-empty intersection, set VR0 to the
3872 union of VR0 and VR1. */
3874 static void
3876 {
3878 {
3881 }
3884 {
3885 /* Nothing to do. VR0 already has the resulting range. */
3887 }
3890 {
3891 /* Nothing to do. VR0 already has the resulting range. */
3893 }
3896 {
3899 }
3902 {
3903 /* If VR0 and VR1 have a non-empty intersection, compute the
3904 union of both ranges. */
3906 {
3910 /* The lower limit of the new range is the minimum of the
3911 two ranges. If they cannot be compared, the result is
3912 VARYING. */
3918 else
3919 {
3922 }
3924 /* Similarly, the upper limit of the new range is the
3925 maximum of the two ranges. If they cannot be compared,
3926 the result is VARYING. */
3932 else
3933 {
3936 }
3938 /* The resulting set of equivalences is the intersection of
3939 the two sets. */
3946 }
3947 else
3949 }
3951 {
3952 /* Two anti-ranges meet only if they are both identical. */
3956 {
3957 /* The resulting set of equivalences is the intersection of
3958 the two sets. */
3963 }
3964 else
3966 }
3968 {
3969 /* A numeric range [VAL1, VAL2] and an anti-range ~[VAL3, VAL4]
3970 meet only if the ranges have an empty intersection. The
3971 result of the meet operation is the anti-range. */
3975 {
3976 /* Copy most of VR1 into VR0. Don't copy VR1's equivalence
3977 set. We need to compute the intersection of the two
3978 equivalence sets. */
3982 /* The resulting set of equivalences is the intersection of
3983 the two sets. */
3988 }
3989 else
3991 }
3992 else
3997 no_meet:
3998 /* The two range VR0 and VR1 do not meet. Before giving up and
3999 setting the result to VARYING, see if we can at least derive a
4000 useful anti-range. FIXME, all this nonsense about distinguishing
4001 anti-ranges from ranges is necessary because of the odd
4002 semantics of range_includes_zero_p and friends. */
4009 {
4012 /* Since this meet operation did not result from the meeting of
4013 two equivalent names, VR0 cannot have any equivalences. */
4016 }
4017 else
4019 }
4022 /* Visit all arguments for PHI node PHI that flow through executable
4023 edges. If a valid value range can be derived from all the incoming
4024 value ranges, set a new range for the LHS of PHI. */
4026 static enum ssa_prop_result
4028 {
4037 {
4040 }
4043 {
4047 {
4052 }
4055 {
4057 value_range_t vr_arg;
4061 else
4062 {
4067 }
4070 {
4076 }
4082 }
4083 }
4088 /* To prevent infinite iterations in the algorithm, derive ranges
4089 when the new value is slightly bigger or smaller than the
4090 previous one. */
4092 {
4094 {
4098 /* If the new minimum is smaller or larger than the previous
4099 one, go all the way to -INF. In the first case, to avoid
4100 iterating millions of times to reach -INF, and in the
4101 other case to avoid infinite bouncing between different
4102 minimums. */
4106 /* Similarly, if the new maximum is smaller or larger than
4107 the previous one, go all the way to +INF. */
4111 /* If we ended up with a (-INF, +INF) range, set it to
4112 VARYING. */
4116 }
4117 }
4119 /* If the new range is different than the previous value, keep
4120 iterating. */
4124 /* Nothing changed, don't add outgoing edges. */
4127 /* No match found. Set the LHS to VARYING. */
4128 varying:
4131 }
4133 /* Simplify a division or modulo operator to a right shift or
4134 bitwise and if the first operand is unsigned or is greater
4135 than zero and the second operand is an exact power of two. */
4137 static void
4139 {
4145 {
4147 }
4148 else
4149 {
4151 }
4154 {
4155 tree t;
4160 {
4163 }
4164 else
4165 {
4170 }
4174 }
4175 }
4177 /* If the operand to an ABS_EXPR is >= 0, then eliminate the
4178 ABS_EXPR. If the operand is <= 0, then simplify the
4179 ABS_EXPR into a NEGATE_EXPR. */
4181 static void
4183 {
4190 {
4192 }
4194 {
4197 {
4201 {
4206 }
4207 }
4211 {
4212 tree t;
4216 else
4221 }
4222 }
4223 }
4225 /* We are comparing trees OP0 and OP1 using COND_CODE. OP0 has
4226 a known value range VR.
4228 If there is one and only one value which will satisfy the
4229 conditional, then return that value. Else return NULL. */
4231 static tree
4234 {
4238 /* Extract minimum/maximum values which satisfy the
4239 the conditional as it was written. */
4241 {
4246 {
4249 }
4250 }
4252 {
4257 {
4260 }
4261 }
4263 /* Now refine the minimum and maximum values using any
4264 value range information we have for op0. */
4266 {
4269 else
4273 else
4276 /* If the new min/max values have converged to a single value,
4277 then there is only one value which can satisfy the condition,
4278 return that value. */
4281 }
4283 }
4285 /* Simplify a conditional using a relational operator to an equality
4286 test if the range information indicates only one value can satisfy
4287 the original conditional. */
4289 static void
4291 {
4302 {
4305 /* If we have range information for OP0, then we might be
4306 able to simplify this conditional. */
4308 {
4312 {
4314 {
4318 }
4325 {
4328 }
4331 }
4333 /* Try again after inverting the condition. We only deal
4334 with integral types here, so no need to worry about
4335 issues with inverting FP comparisons. */
4340 {
4342 {
4346 }
4353 {
4356 }
4359 }
4360 }
4361 }
4362 }
4364 /* Simplify STMT using ranges if possible. */
4366 void
4368 {
4370 {
4374 /* Transform TRUNC_DIV_EXPR and TRUNC_MOD_EXPR into RSHIFT_EXPR
4375 and BIT_AND_EXPR respectively if the first operand is greater
4376 than zero and the second operand is an exact power of two. */
4382 /* Transform ABS (X) into X or -X as appropriate. */
4387 }
4390 {
4392 }
4393 }
4395 /* Stack of dest,src equivalency pairs that need to be restored after
4396 each attempt to thread a block's incoming edge to an outgoing edge.
4398 A NULL entry is used to mark the end of pairs which need to be
4399 restored. */
4402 /* A trivial wrapper so that we can present the generic jump
4403 threading code with a simple API for simplifying statements. */
4404 static tree
4406 {
4407 /* We only use VRP information to simplify conditionals. This is
4408 overly conservative, but it's unclear if doing more would be
4409 worth the compile time cost. */
4414 }
4416 /* Blocks which have more than one predecessor and more than
4417 one successor present jump threading opportunities. ie,
4418 when the block is reached from a specific predecessor, we
4419 may be able to determine which of the outgoing edges will
4420 be traversed. When this optimization applies, we are able
4421 to avoid conditionals at runtime and we may expose secondary
4422 optimization opportunities.
4424 This routine is effectively a driver for the generic jump
4425 threading code. It basically just presents the generic code
4426 with edges that may be suitable for jump threading.
4428 Unlike DOM, we do not iterate VRP if jump threading was successful.
4429 While iterating may expose new opportunities for VRP, it is expected
4430 those opportunities would be very limited and the compile time cost
4431 to expose those opportunities would be significant.
4433 As jump threading opportunities are discovered, they are registered
4434 for later realization. */
4436 static void
4438 {
4439 basic_block bb;
4440 tree dummy;
4442 /* Ugh. When substituting values earlier in this pass we can
4443 wipe the dominance information. So rebuild the dominator
4444 information as we need it within the jump threading code. */
4447 /* We do not allow VRP information to be used for jump threading
4448 across a back edge in the CFG. Otherwise it becomes too
4449 difficult to avoid eliminating loop exit tests. Of course
4450 EDGE_DFS_BACK is not accurate at this time so we have to
4451 recompute it. */
4454 /* Allocate our unwinder stack to unwind any temporary equivalences
4455 that might be recorded. */
4458 /* To avoid lots of silly node creation, we create a single
4459 conditional and just modify it in-place when attempting to
4460 thread jumps. */
4464 /* Walk through all the blocks finding those which present a
4465 potential jump threading opportunity. We could set this up
4466 as a dominator walker and record data during the walk, but
4467 I doubt it's worth the effort for the classes of jump
4468 threading opportunities we are trying to identify at this
4469 point in compilation. */
4471 {
4474 /* If the generic jump threading code does not find this block
4475 interesting, then there is nothing to do. */
4479 /* We only care about blocks ending in a COND_EXPR. While there
4480 may be some value in handling SWITCH_EXPR here, I doubt it's
4481 terribly important. */
4486 /* We're basically looking for any kind of conditional with
4487 integral type arguments. */
4497 {
4498 edge_iterator ei;
4499 edge e;
4501 /* We've got a block with multiple predecessors and multiple
4502 successors which also ends in a suitable conditional. For
4503 each predecessor, see if we can thread it to a specific
4504 successor. */
4506 {
4507 /* Do not thread across back edges or abnormal edges
4508 in the CFG. */
4514 simplify_stmt_for_jump_threading);
4515 }
4516 }
4517 }
4519 /* We do not actually update the CFG or SSA graphs at this point as
4520 ASSERT_EXPRs are still in the IL and cfg cleanup code does not yet
4521 handle ASSERT_EXPRs gracefully. */
4522 }
4524 /* We identified all the jump threading opportunities earlier, but could
4525 not transform the CFG at that time. This routine transforms the
4526 CFG and arranges for the dominator tree to be rebuilt if necessary.
4528 Note the SSA graph update will occur during the normal TODO
4529 processing by the pass manager. */
4530 static void
4532 {
4536 /* If we threaded jumps, then we need to recompute the dominance
4537 information, to safely do that we must clean up the CFG first. */
4539 {
4543 }
4545 }
4548 /* Traverse all the blocks folding conditionals with known ranges. */
4550 static void
4552 {
4558 {
4562 }
4564 /* We may have ended with ranges that have exactly one value. Those
4565 values can be substituted as any other copy/const propagated
4566 value using substitute_and_fold. */
4575 {
4578 }
4581 {
4582 /* We found no single-valued ranges, don't waste time trying to
4583 do single value substitution in substitute_and_fold. */
4586 }
4590 /* We must identify jump threading opportunities before we release
4591 the datastructures built by VRP. */
4594 /* Free allocated memory. */
4597 {
4600 }
4605 /* So that we can distinguish between VRP data being available
4606 and not available. */
4608 }
4611 /* Main entry point to VRP (Value Range Propagation). This pass is
4612 loosely based on J. R. C. Patterson, ``Accurate Static Branch
4613 Prediction by Value Range Propagation,'' in SIGPLAN Conference on
4614 Programming Language Design and Implementation, pp. 67-78, 1995.
4615 Also available at http://citeseer.ist.psu.edu/patterson95accurate.html
4617 This is essentially an SSA-CCP pass modified to deal with ranges
4618 instead of constants.
4620 While propagating ranges, we may find that two or more SSA name
4621 have equivalent, though distinct ranges. For instance,
4623 1 x_9 = p_3->a;
4624 2 p_4 = ASSERT_EXPR <p_3, p_3 != 0>
4625 3 if (p_4 == q_2)
4626 4 p_5 = ASSERT_EXPR <p_4, p_4 == q_2>;
4627 5 endif
4628 6 if (q_2)
4630 In the code above, pointer p_5 has range [q_2, q_2], but from the
4631 code we can also determine that p_5 cannot be NULL and, if q_2 had
4632 a non-varying range, p_5's range should also be compatible with it.
4634 These equivalences are created by two expressions: ASSERT_EXPR and
4635 copy operations. Since p_5 is an assertion on p_4, and p_4 was the
4636 result of another assertion, then we can use the fact that p_5 and
4637 p_4 are equivalent when evaluating p_5's range.
4639 Together with value ranges, we also propagate these equivalences
4640 between names so that we can take advantage of information from
4641 multiple ranges when doing final replacement. Note that this
4642 equivalency relation is transitive but not symmetric.
4644 In the example above, p_5 is equivalent to p_4, q_2 and p_3, but we
4645 cannot assert that q_2 is equivalent to p_5 because q_2 may be used
4646 in contexts where that assertion does not hold (e.g., in line 6).
4648 TODO, the main difference between this pass and Patterson's is that
4649 we do not propagate edge probabilities. We only compute whether
4650 edges can be taken or not. That is, instead of having a spectrum
4651 of jump probabilities between 0 and 1, we only deal with 0, 1 and
4652 DON'T KNOW. In the future, it may be worthwhile to propagate
4653 probabilities to aid branch prediction. */
4655 static unsigned int
4657 {
4669 {
4673 }
4675 /* ASSERT_EXPRs must be removed before finalizing jump threads
4676 as finalizing jump threads calls the CFG cleanup code which
4677 does not properly handle ASSERT_EXPRs. */
4680 /* If we exposed any new variables, go ahead and put them into
4681 SSA form now, before we handle jump threading. This simplifies
4682 interactions between rewriting of _DECL nodes into SSA form
4683 and rewriting SSA_NAME nodes into SSA form after block
4684 duplication and CFG manipulation. */
4689 }
4691 static bool
4693 {
4695 }
4698 {
4710 TODO_cleanup_cfg
4711 | TODO_ggc_collect
4712 | TODO_verify_ssa
4713 | TODO_dump_func
4714 | TODO_update_ssa
4717 };