This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH RFC: Use explicit representation of infinity in VRP


Ian Lance Taylor wrote on 02/27/07 10:50:

+/* Return whether TYPE can support our overflow infinity
+   representation: we use the TREE_OVERFLOW flag, which only exists
+   for consteants.  If TYPE doesn't support this, we don't optimize

s/consteants/constants/


@@ -1915,6 +2267,40 @@ extract_range_from_unary_expr (value_ran
       /* Otherwise, operate on each end of the range.  */
       min = fold_unary_to_constant (code, TREE_TYPE (expr), vr0.min);
       max = fold_unary_to_constant (code, TREE_TYPE (expr), vr0.max);
+
+      if (uses_overflow_infinity (TREE_TYPE (expr)))
+	{
+	  gcc_assert (code != NEGATE_EXPR && code != ABS_EXPR);
+	  if (is_overflow_infinity (vr0.min))
+	    min = vr0.min;
+	  else if (TREE_OVERFLOW (min))
+	    {
+	      if (supports_overflow_infinity (TREE_TYPE (expr)))

I'm confused. If uses_overflow_infinity (TYPE) is true, why would support_overflow_infinity (TYPE) be false? (I'm going by the names of the predicates, it may be an indication that they need to be renamed).


+  bool sop = false;
+  tree val = vrp_evaluate_conditional (expr, false, &sop);
+
+  /* A disadvantage of using a special infinity as an overflow
+     representation is that we lose the ability to record overflow
+     when we don't have an infinity.  So we have to ignore a result
+     which relies on overflow.  */
+

Sorry, I don't follow this one. You mean when the type does not have an infinity value? Show me an example of this?


@@ -2412,7 +2855,9 @@ dump_value_range (FILE *file, value_rang
if (INTEGRAL_TYPE_P (type)
&& !TYPE_UNSIGNED (type)
- && vr->min == TYPE_MIN_VALUE (type))
+ && (uses_overflow_infinity (type)
+ ? is_negative_overflow_infinity (vr->min)
+ : vr->min == TYPE_MIN_VALUE (type)))
fprintf (file, "-INF");
else
print_generic_expr (file, vr->min, 0);

Here in dump_value_range we should distinguish INF from INF(OVF) (or some other overflow indicator).

+	    {
+	      /* If we will end up with a (-INF, +INF) range, set it
+		 to VARYING.  */
+	      if (is_negative_overflow_infinity (vr_result.min)
+		  || (vr_result.min
+		      == TYPE_MIN_VALUE (TREE_TYPE (vr_result.min))))
+		goto varying;
+
+	      if (!uses_overflow_infinity (TREE_TYPE (vr_result.max)))
+		vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
+	      else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))
+		vr_result.max =
+		  positive_overflow_infinity (TREE_TYPE (vr_result.max));
+	      else
+		goto varying;
+	    }
 	}

Any compile time effects of this? Changing the probability of getting VARYING values sometimes has a significant effect on simulation times.

@@ -1112,7 +1113,8 @@ fold_predicate_in (tree stmt)
else
return false;
- val = vrp_evaluate_conditional (*pred_p, true);
+ sop = false;
+ val = vrp_evaluate_conditional (*pred_p, true, &sop);

I guess you plan to use this in the follow up patch?


I find it a bit unfortunate that we have to munge up an optimization so much just
to get better diagnostics.  It's a slippery slope similar to the one we have
with -Wuninitialized.  I would love to see all the warning machinery use a
totally separate and optimization-independent mechanism.  But I realize that
we are not quite there yet, so I don't have a problem with this idea.

Test cases coming in with the actual warning patch, right?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]