>Number:         154445
>Category:       gnu
>Synopsis:       Attempt to "fix" gcc -ftree-vrp
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 01 19:10:06 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Pedro Giffuni
>Release:        8.1-Release
>Organization:
>Environment:
FreeBSD mogwai.giffuni.net 8.1-RELEASE FreeBSD 8.1-RELEASE #1: Sat Jul 17 
14:19:59 PDT 2010     
r...@build8x64.pcbsd.org:/usr/obj/usr/pcbsd-build81/fbsd-source/8.1/sys/PCBSD  
amd64

>Description:
gcc's tree-vrp optimization was turned of by default on FreeBSD (svn 172419) 
because it's known to generate bad code, specially on java ports, Looking at 
the gcc 4.2 branch logs I found the following change that appears to fix it.

2007-10-10  Richard Guenther
PR tree-optimization/33099
PR tree-optimization/33381
* tree-vrp.c (adjust_range_with_scev): Do not adjust ranges
from pointer typed chrecs.

Unfortunately this change is GPL3 and the owner will not reconsider changing 
the license. A workaround that seems to work in my system is undoing the last 
patch in that file/function.

This is not the ideal fix but since the code is disabled by default anyways it 
works well enough.
>How-To-Repeat:
Check gcc PR 330099 and build the testcase with -ftree-vrp
>Fix:
REVERSE (patch -R) the attached patch in /usr/src/contrib:

2007-06-04  Ian Lance Taylor

* tree-vrp.c (adjust_range_with_scev): When loop is not expected
to overflow, reduce overflow infinity to regular infinity.

Patch attached with submission follows:

--- gcc/tree-vrp.c      2007/05/30 22:52:02     125204
+++ gcc/tree-vrp.c      2007/06/04 21:58:42     125320
@@ -2558,6 +2558,13 @@
              if (compare_values (min, max) == 1)
                return;
            }
+
+         /* According to the loop information, the variable does not
+            overflow.  If we think it does, probably because of an
+            overflow due to arithmetic on a different INF value,
+            reset now.  */
+         if (is_negative_overflow_infinity (min))
+           min = tmin;
        }
       else
        {
@@ -2570,12 +2577,61 @@
              if (compare_values (min, max) == 1)
                return;
            }
+
+         if (is_positive_overflow_infinity (max))
+           max = tmax;
        }
 
       set_value_range (vr, VR_RANGE, min, max, vr->equiv);
     }
 }
 
+/* Return true if VAR may overflow at STMT.  This checks any available
+   loop information to see if we can determine that VAR does not
+   overflow.  */
+
+static bool
+vrp_var_may_overflow (tree var, tree stmt)
+{
+  struct loop *l;
+  tree chrec, init, step;
+
+  if (current_loops == NULL)
+    return true;
+
+  l = loop_containing_stmt (stmt);
+  if (l == NULL)
+    return true;
+
+  chrec = instantiate_parameters (l, analyze_scalar_evolution (l, var));
+  if (TREE_CODE (chrec) != POLYNOMIAL_CHREC)
+    return true;
+
+  init = initial_condition_in_loop_num (chrec, l->num);
+  step = evolution_part_in_loop_num (chrec, l->num);
+
+  if (step == NULL_TREE
+      || !is_gimple_min_invariant (step)
+      || !valid_value_p (init))
+    return true;
+
+  /* If we get here, we know something useful about VAR based on the
+     loop information.  If it wraps, it may overflow.  */
+
+  if (scev_probably_wraps_p (init, step, stmt,
+                            current_loops->parray[CHREC_VARIABLE (chrec)],
+                            true))
+    return true;
+
+  if (dump_file && (dump_flags & TDF_DETAILS) != 0)
+    {
+      print_generic_expr (dump_file, var, 0);
+      fprintf (dump_file, ": loop information indicates does not overflow\n");
+    }
+
+  return false;
+}
+
 
 /* Given two numeric value ranges VR0, VR1 and a comparison code COMP:
    
@@ -4786,7 +4842,8 @@
              if (vrp_val_is_max (vr_result.max))
                goto varying;
 
-             if (!needs_overflow_infinity (TREE_TYPE (vr_result.min)))
+             if (!needs_overflow_infinity (TREE_TYPE (vr_result.min))
+                 || !vrp_var_may_overflow (lhs, phi))
                vr_result.min = TYPE_MIN_VALUE (TREE_TYPE (vr_result.min));
              else if (supports_overflow_infinity (TREE_TYPE (vr_result.min)))
                vr_result.min =
@@ -4804,7 +4861,8 @@
              if (vrp_val_is_min (vr_result.min))
                goto varying;
 
-             if (!needs_overflow_infinity (TREE_TYPE (vr_result.max)))
+             if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))
+                 || !vrp_var_may_overflow (lhs, phi))
                vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
              else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))
                vr_result.max =


>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Reply via email to