+++ /dev/null
-Date: Thu, 23 Jun 2005 07:39:44 -0700
-From: Kazu Hirata <kazu at sethra dot codesourcery dot com>
-Subject: [patch] tree-vrp.c: Avoid VR_ANTI_RANGE in certain binary expression. (Take 2)
-
-Hi,
-
-Attached is a revised version of the patch posted at
-
-http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01729.html
-
-This version tries a bit harder not to drop to VR_VARYING right away
-when a binary expression involves VR_ANTI_RANGE. Specifically, We
-drop to VR_VARYING only if a binary expression involving VR_ANTI_RANGE
-is PLUS_EXPR, MINUS_EXPR, or unsigned MULT_EXPR. Other cases are left
-intact.
-
-The testcase has been updated to cover MINUS_EXPR and unsigned
-MULT_EXPR as well as PLUS_EXPR, which was already in the previous
-version of the testcase.
-
-Tested on x86_64-pc-linux-gnu. OK to apply?
-
-Kazu Hirata
-
-2005-06-23 Kazu Hirata <kazu@codesourcery.com>
-
- PR tree-optimization/22026
- * tree-vrp.c (extract_range_from_binary_expr): Drop to
- VR_VARYING if a binary expression involving VR_ANTI_RANGE is
- PLUS_EXPR, MINUS_EXPR, or unsigned MULT_EXPR.
-
-2005-06-23 Kazu Hirata <kazu@codesourcery.com>
-
- PR tree-optimization/22026
- * gcc.dg/tree-ssa/pr22026.c: New.
-
---- a/gcc/tree-vrp.c 21 Jun 2005 18:46:19 -0000 2.32
-+++ b/gcc/tree-vrp.c 22 Jun 2005 20:33:01 -0000
-@@ -1100,6 +1100,19 @@ extract_range_from_binary_expr (value_ra
- || code == MIN_EXPR
- || code == MAX_EXPR)
- {
-+ /* If we have a PLUS_EXPR with two VR_ANTI_RANGEs, drop to
-+ VR_VARYING. It would take more effort to compute a precise
-+ range for such a case. For example, if we have op0 == 1 and
-+ op1 == -1 with their ranges both being ~[0,0], we would have
-+ op0 + op1 == 0, so we cannot claim that the sum is in ~[0,0].
-+ Note that we are guaranteed to have vr0.type == vr1.type at
-+ this point. */
-+ if (code == PLUS_EXPR && vr0.type == VR_ANTI_RANGE)
-+ {
-+ set_value_range_to_varying (vr);
-+ return;
-+ }
-+
- /* For operations that make the resulting range directly
- proportional to the original ranges, apply the operation to
- the same end of each range. */
-@@ -1116,6 +1129,22 @@ extract_range_from_binary_expr (value_ra
- tree val[4];
- size_t i;
-
-+ /* If we have an unsigned MULT_EXPR with two VR_ANTI_RANGEs,
-+ drop to VR_VARYING. It would take more effort to compute a
-+ precise range for such a case. For example, if we have
-+ op0 == 65536 and op1 == 65536 with their ranges both being
-+ ~[0,0] on a 32-bit machine, we would have op0 * op1 == 0, so
-+ we cannot claim that the product is in ~[0,0]. Note that we
-+ are guaranteed to have vr0.type == vr1.type at this
-+ point. */
-+ if (code == MULT_EXPR
-+ && vr0.type == VR_ANTI_RANGE
-+ && (flag_wrapv || TYPE_UNSIGNED (TREE_TYPE (op0))))
-+ {
-+ set_value_range_to_varying (vr);
-+ return;
-+ }
-+
- /* Multiplications and divisions are a bit tricky to handle,
- depending on the mix of signs we have in the two ranges, we
- need to operate on different values to get the minimum and
-@@ -1181,7 +1210,20 @@ extract_range_from_binary_expr (value_ra
- }
- else if (code == MINUS_EXPR)
- {
-+ /* If we have a MINUS_EXPR with two VR_ANTI_RANGEs, drop to
-+ VR_VARYING. It would take more effort to compute a precise
-+ range for such a case. For example, if we have op0 == 1 and
-+ op1 == 1 with their ranges both being ~[0,0], we would have
-+ op0 - op1 == 0, so we cannot claim that the difference is in
-+ ~[0,0]. Note that we are guaranteed to have
-+ vr0.type == vr1.type at this point. */
-+ if (vr0.type == VR_ANTI_RANGE)
-+ {
-+ set_value_range_to_varying (vr);
-+ return;
-+ }
-+
- /* For MINUS_EXPR, apply the operation to the opposite ends of
- each range. */
- min = vrp_int_const_binop (code, vr0.min, vr1.max);