gcc-pr22026.patch

   1 Date: Thu, 23 Jun 2005 07:39:44 -0700
   2 From: Kazu Hirata <kazu at sethra dot codesourcery dot com>
   3 Subject: [patch] tree-vrp.c: Avoid VR_ANTI_RANGE in certain binary expression. (Take 2)
   4
   5 Hi,
   6
   7 Attached is a revised version of the patch posted at
   8
   9 http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01729.html
  10
  11 This version tries a bit harder not to drop to VR_VARYING right away
  12 when a binary expression involves VR_ANTI_RANGE.  Specifically, We
  13 drop to VR_VARYING only if a binary expression involving VR_ANTI_RANGE
  14 is PLUS_EXPR, MINUS_EXPR, or unsigned MULT_EXPR.  Other cases are left
  15 intact.
  16
  17 The testcase has been updated to cover MINUS_EXPR and unsigned
  18 MULT_EXPR as well as PLUS_EXPR, which was already in the previous
  19 version of the testcase.
  20
  21 Tested on x86_64-pc-linux-gnu.  OK to apply?
  22
  23 Kazu Hirata
  24
  25 2005-06-23  Kazu Hirata  <kazu@codesourcery.com>
  26
  27         PR tree-optimization/22026
  28         * tree-vrp.c (extract_range_from_binary_expr): Drop to
  29         VR_VARYING if a binary expression involving VR_ANTI_RANGE is
  30         PLUS_EXPR, MINUS_EXPR, or unsigned MULT_EXPR.
  31
  32 2005-06-23  Kazu Hirata  <kazu@codesourcery.com>
  33
  34         PR tree-optimization/22026
  35         * gcc.dg/tree-ssa/pr22026.c: New.
  36
  37 --- a/gcc/tree-vrp.c    21 Jun 2005 18:46:19 -0000      2.32
  38 +++ b/gcc/tree-vrp.c    22 Jun 2005 20:33:01 -0000
  39 @@ -1100,6 +1100,19 @@ extract_range_from_binary_expr (value_ra
  40            || code == MIN_EXPR
  41            || code == MAX_EXPR)
  42      {
  43 +      /* If we have a PLUS_EXPR with two VR_ANTI_RANGEs, drop to
  44 +        VR_VARYING.  It would take more effort to compute a precise
  45 +        range for such a case.  For example, if we have op0 == 1 and
  46 +        op1 == -1 with their ranges both being ~[0,0], we would have
  47 +        op0 + op1 == 0, so we cannot claim that the sum is in ~[0,0].
  48 +        Note that we are guaranteed to have vr0.type == vr1.type at
  49 +        this point.  */
  50 +      if (code == PLUS_EXPR && vr0.type == VR_ANTI_RANGE)
  51 +       {
  52 +         set_value_range_to_varying (vr);
  53 +         return;
  54 +       }
  55 +
  56        /* For operations that make the resulting range directly
  57          proportional to the original ranges, apply the operation to
  58          the same end of each range.  */
  59 @@ -1116,6 +1129,22 @@ extract_range_from_binary_expr (value_ra
  60        tree val[4];
  61        size_t i;
  62
  63 +      /* If we have an unsigned MULT_EXPR with two VR_ANTI_RANGEs,
  64 +        drop to VR_VARYING.  It would take more effort to compute a
  65 +        precise range for such a case.  For example, if we have
  66 +        op0 == 65536 and op1 == 65536 with their ranges both being
  67 +        ~[0,0] on a 32-bit machine, we would have op0 * op1 == 0, so
  68 +        we cannot claim that the product is in ~[0,0].  Note that we
  69 +        are guaranteed to have vr0.type == vr1.type at this
  70 +        point.  */
  71 +      if (code == MULT_EXPR
  72 +         && vr0.type == VR_ANTI_RANGE
  73 +         && (flag_wrapv || TYPE_UNSIGNED (TREE_TYPE (op0))))
  74 +       {
  75 +         set_value_range_to_varying (vr);
  76 +         return;
  77 +       }
  78 +
  79        /* Multiplications and divisions are a bit tricky to handle,
  80          depending on the mix of signs we have in the two ranges, we
  81          need to operate on different values to get the minimum and
  82 @@ -1181,7 +1210,20 @@ extract_range_from_binary_expr (value_ra
  83      }
  84    else if (code == MINUS_EXPR)
  85      {
  86 +      /* If we have a MINUS_EXPR with two VR_ANTI_RANGEs, drop to
  87 +        VR_VARYING.  It would take more effort to compute a precise
  88 +        range for such a case.  For example, if we have op0 == 1 and
  89 +        op1 == 1 with their ranges both being ~[0,0], we would have
  90 +        op0 - op1 == 0, so we cannot claim that the difference is in
  91 +        ~[0,0].  Note that we are guaranteed to have
  92 +        vr0.type == vr1.type at this point.  */
  93 +      if (vr0.type == VR_ANTI_RANGE)
  94 +       {
  95 +         set_value_range_to_varying (vr);
  96 +         return;
  97 +       }
  98 +
  99        /* For MINUS_EXPR, apply the operation to the opposite ends of
 100          each range.  */
 101        min = vrp_int_const_binop (code, vr0.min, vr1.max);