misc VRP cleanups for value_range API

Message ID 04208e74-4e3b-15b0-91f0-d8f90372d26a@redhat.com
State New
Headers show
Series
  • misc VRP cleanups for value_range API
Related show

Commit Message

Aldy Hernandez Nov. 8, 2018, 12:42 p.m.
Stupid boring changes.

OK?

Comments

Richard Biener Nov. 8, 2018, 2:31 p.m. | #1
On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez <aldyh@redhat.com> wrote:
>

> Stupid boring changes.

>

> OK?


Well, IMHO using m_min is making clear you are accessing a member
while using min () does not.

So no, please do not make this kind of changes?

Richard.
Aldy Hernandez Nov. 8, 2018, 2:33 p.m. | #2
On 11/8/18 9:31 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez <aldyh@redhat.com> wrote:

>>

>> Stupid boring changes.

>>

>> OK?

> 

> Well, IMHO using m_min is making clear you are accessing a member

> while using min () does not.


There is already prior art here.  I believe I discussed this before and 
committed some bits like this.

> 

> So no, please do not make this kind of changes?


It also makes it easier for my work going forward.  So not technically 
needed, but it would make my life easier as I change the min/max 
implementation in the distant future.  Please?

Aldy
Richard Biener Nov. 8, 2018, 2:50 p.m. | #3
On Thu, Nov 8, 2018 at 3:34 PM Aldy Hernandez <aldyh@redhat.com> wrote:
>

>

>

> On 11/8/18 9:31 AM, Richard Biener wrote:

> > On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez <aldyh@redhat.com> wrote:

> >>

> >> Stupid boring changes.

> >>

> >> OK?

> >

> > Well, IMHO using m_min is making clear you are accessing a member

> > while using min () does not.

>

> There is already prior art here.  I believe I discussed this before and

> committed some bits like this.

>

> >

> > So no, please do not make this kind of changes?

>

> It also makes it easier for my work going forward.  So not technically

> needed, but it would make my life easier as I change the min/max

> implementation in the distant future.  Please?


Hmfp :/

OK

> Aldy

Patch

            * tree-vrp.c (value_range::check): Do not access internals
            directly.
            (value_range::singleton_p): Same.
            (value_range::type): Same.
            (vrp_finalize): Use value_range API.

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 7af676a416d..3ccf2e491d6 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -157,7 +157,7 @@  value_range::check ()
       }
     case VR_UNDEFINED:
     case VR_VARYING:
-      gcc_assert (!m_min && !m_max);
+      gcc_assert (!min () && !max ());
       gcc_assert (!m_equiv || bitmap_empty_p (m_equiv));
       break;
     default:
@@ -291,11 +291,11 @@  bool
 value_range::singleton_p (tree *result) const
 {
   if (m_kind == VR_RANGE
-      && vrp_operand_equal_p (m_min, m_max)
-      && is_gimple_min_invariant (m_min))
+      && vrp_operand_equal_p (min (), max ())
+      && is_gimple_min_invariant (min ()))
     {
       if (result)
-        *result = m_min;
+        *result = min ();
       return true;
     }
   return false;
@@ -306,8 +306,8 @@  value_range::type () const
 {
   /* Types are only valid for VR_RANGE and VR_ANTI_RANGE, which are
      known to have non-zero min/max.  */
-  gcc_assert (m_min);
-  return TREE_TYPE (m_min);
+  gcc_assert (min ());
+  return TREE_TYPE (min ());
 }
 
 /* Dump value range to FILE.  */
@@ -6558,9 +6558,7 @@  vrp_prop::vrp_finalize (bool warn_array_bounds_p)
 	  && range_includes_zero_p (vr) == 0)
 	set_ptr_nonnull (name);
       else if (!POINTER_TYPE_P (TREE_TYPE (name)))
-	set_range_info (name, vr->kind (),
-			wi::to_wide (vr->min ()),
-			wi::to_wide (vr->max ()));
+	set_range_info (name, *vr);
     }
 
   /* If we're checking array refs, we want to merge information on