| Message ID | 76edd771-749d-f85f-2d0e-84e714abb78e@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Fri, Oct 7, 2016 at 12:00 AM, kugan <kugan.vivekanandarajah@linaro.org> wrote: > Hi, > > In vrp intersect_ranges, Richard recently changed it to create integer value > ranges when it is integer singleton. > > Maybe we should do the same when the other range is a complex ranges with > SSA_NAME (like [x+2, +INF])? > > Attached patch tries to do this. There are cases where it will be beneficial > as the testcase in the patch. (For this testcase to work with Early VRP, we > need the patch posted at > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00413.html) > > Bootstrapped and regression tested on x86_64-linux-gnu with no new > regressions. This is not clearly a win, in fact it can completely lose an ASSERT_EXPR because there is no way to add its effect back as an equivalence. The current choice of always using the "left" keeps the ASSERT_EXPR range and is able to record the other range via an equivalence. My thought on this was that we need to separate "ranges" and associated SSA names so we can introduce new ranges w/o the need for an SSA name (and thus we can create an equivalence to the ASSERT_EXPR range). IIRC I started on this at some point but never finished it ... Richard. > Thanks, > Kugan > > > gcc/testsuite/ChangeLog: > > 2016-10-07 Kugan Vivekanandarajah <kuganv@linaro.org> > > * gcc.dg/tree-ssa/evrp6.c: New test. > > gcc/ChangeLog: > > 2016-10-07 Kugan Vivekanandarajah <kuganv@linaro.org> > > * tree-vrp.c (intersect_ranges): If we failed to handle > the intersection and the other range involves computation with > symbolic values, choose integer range if available. > > >
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/evrp6.c b/gcc/testsuite/gcc.dg/tree-ssa/evrp6.c index e69de29..3740da0 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/evrp6.c +++ b/gcc/testsuite/gcc.dg/tree-ssa/evrp6.c @@ -0,0 +1,21 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-evrp" } */ + +extern void abort (void); + +int +foo (int k, int j) +{ + if (j >= 10) + { + if (j < k) + { + k++; + if (k < 10) + abort (); + } + } + + return j; +} +/* { dg-final { scan-tree-dump "\\\[12, \\+INF" "evrp" } } */ diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 7a08be7..2706854 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -8553,11 +8553,26 @@ intersect_ranges (enum value_range_type *vr0type, gcc_unreachable (); } + /* If one is a complex value range involving SSA_NAME + and other is INTEGER_CST, prefer INTEGER_CST. */ + else if (vr1type == VR_RANGE + && INTEGER_CST == TREE_CODE (vr1min) + && INTEGER_CST == TREE_CODE (vr1max) + && (((INTEGER_CST != TREE_CODE (*vr0min) + && SSA_NAME != TREE_CODE (*vr0min)) + || ((INTEGER_CST != TREE_CODE (*vr0max) + && SSA_NAME != TREE_CODE (*vr0max)))))) + { + *vr0type = vr1type; + *vr0min = vr1min; + *vr0max = vr1max; + } + /* As a fallback simply use { *VRTYPE, *VR0MIN, *VR0MAX } as result for the intersection. That's always a conservative correct estimate unless VR1 is a constant singleton range in which case we choose that. */ - if (vr1type == VR_RANGE + else if (vr1type == VR_RANGE && is_gimple_min_invariant (vr1min) && vrp_operand_equal_p (vr1min, vr1max)) {