implement value_range::domain_p()

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

implement value_range::domain_p()

Aldy Hernandez-2
I believe I've seen this idiom more than once.  I know for sure I've
used it in our ssa-range branch :).  I'll hunt for the other uses and
adjust accordingly.

OK?

curr.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: implement value_range::domain_p()

Richard Biener-2
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez <[hidden email]> wrote:
>
> I believe I've seen this idiom more than once.  I know for sure I've
> used it in our ssa-range branch :).  I'll hunt for the other uses and
> adjust accordingly.

domain_p?!  Isn't that the same as varying_p()?  Also

+  if (m_kind == VR_RANGE)
+    {
+      tree type = TREE_TYPE (type ());
+      value_range vr (VR_RANGE, TYPE_MIN_VALUE (type), TYPE_MAX_VALUE (type));

TYPE_MIN/MAX_VALUE is NULL for pointers

+      return equal_p (vr, /*ignore_equivs=*/true);

But equivs essentially are making the range smaller!  The range
is the intersection of itself with all equiv ranges!

Richard.

+    }


> OK?
Reply | Threaded
Open this post in threaded view
|

Re: implement value_range::domain_p()

Aldy Hernandez-2


On 11/8/18 9:34 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez <[hidden email]> wrote:
>>
>> I believe I've seen this idiom more than once.  I know for sure I've
>> used it in our ssa-range branch :).  I'll hunt for the other uses and
>> adjust accordingly.
>
> domain_p?!  Isn't that the same as varying_p()?  Also

Sigh, yes.  If we kept normalized value_ranges around where [MIN,MAX]
degraded into VR_VARYING, then yes.  But alas, we have two ways of
representing the entire domain.  Don't look at me.  That crap was
already there :).

Another approach would be to call ::set_and_canonicalize() before
checking varying_p() and teach the canonicalize function that [MIN, MAX]
is VR_VARYING.  How does that sound?

Aldy

>
> +  if (m_kind == VR_RANGE)
> +    {
> +      tree type = TREE_TYPE (type ());
> +      value_range vr (VR_RANGE, TYPE_MIN_VALUE (type), TYPE_MAX_VALUE (type));
>
> TYPE_MIN/MAX_VALUE is NULL for pointers
>
> +      return equal_p (vr, /*ignore_equivs=*/true);
>
> But equivs essentially are making the range smaller!  The range
> is the intersection of itself with all equiv ranges!
>
> Richard.
>
> +    }
>
>
>> OK?
Reply | Threaded
Open this post in threaded view
|

Re: implement value_range::domain_p()

Richard Biener-2
On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez <[hidden email]> wrote:

>
>
>
> On 11/8/18 9:34 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez <[hidden email]> wrote:
> >>
> >> I believe I've seen this idiom more than once.  I know for sure I've
> >> used it in our ssa-range branch :).  I'll hunt for the other uses and
> >> adjust accordingly.
> >
> > domain_p?!  Isn't that the same as varying_p()?  Also
>
> Sigh, yes.  If we kept normalized value_ranges around where [MIN,MAX]
> degraded into VR_VARYING, then yes.  But alas, we have two ways of
> representing the entire domain.  Don't look at me.  That crap was
> already there :).
>
> Another approach would be to call ::set_and_canonicalize() before
> checking varying_p() and teach the canonicalize function that [MIN, MAX]
> is VR_VARYING.  How does that sound?

But that's still broken for the case where it has equivalences.  I fear that
if you look at users we'll end up with three or more different
varying_p/domain_p
things all being subtly different...

As said in the other thread we should see to separate equivs out
of the way.

> Aldy
>
> >
> > +  if (m_kind == VR_RANGE)
> > +    {
> > +      tree type = TREE_TYPE (type ());
> > +      value_range vr (VR_RANGE, TYPE_MIN_VALUE (type), TYPE_MAX_VALUE (type));
> >
> > TYPE_MIN/MAX_VALUE is NULL for pointers
> >
> > +      return equal_p (vr, /*ignore_equivs=*/true);
> >
> > But equivs essentially are making the range smaller!  The range
> > is the intersection of itself with all equiv ranges!
> >
> > Richard.
> >
> > +    }
> >
> >
> >> OK?
Reply | Threaded
Open this post in threaded view
|

Re: implement value_range::domain_p()

Aldy Hernandez-2


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

> On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez <[hidden email]> wrote:
>>
>>
>>
>> On 11/8/18 9:34 AM, Richard Biener wrote:
>>> On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez <[hidden email]> wrote:
>>>>
>>>> I believe I've seen this idiom more than once.  I know for sure I've
>>>> used it in our ssa-range branch :).  I'll hunt for the other uses and
>>>> adjust accordingly.
>>>
>>> domain_p?!  Isn't that the same as varying_p()?  Also
>>
>> Sigh, yes.  If we kept normalized value_ranges around where [MIN,MAX]
>> degraded into VR_VARYING, then yes.  But alas, we have two ways of
>> representing the entire domain.  Don't look at me.  That crap was
>> already there :).
>>
>> Another approach would be to call ::set_and_canonicalize() before
>> checking varying_p() and teach the canonicalize function that [MIN, MAX]
>> is VR_VARYING.  How does that sound?
>
> But that's still broken for the case where it has equivalences.  I fear that
> if you look at users we'll end up with three or more different
> varying_p/domain_p
> things all being subtly different...

Bah, I give up.  I don't have time to look into possible subtleties wrt
equivalences right now.  I'll drop this patch.

>
> As said in the other thread we should see to separate equivs out
> of the way.

And as I meant to say in the other thread, I'll buy you many beers if
you can do this for this release :).

Aldy
Reply | Threaded
Open this post in threaded view
|

Re: implement value_range::domain_p()

Richard Biener-2
On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez <[hidden email]> wrote:

>
>
>
> On 11/8/18 9:53 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez <[hidden email]> wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:34 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez <[hidden email]> wrote:
> >>>>
> >>>> I believe I've seen this idiom more than once.  I know for sure I've
> >>>> used it in our ssa-range branch :).  I'll hunt for the other uses and
> >>>> adjust accordingly.
> >>>
> >>> domain_p?!  Isn't that the same as varying_p()?  Also
> >>
> >> Sigh, yes.  If we kept normalized value_ranges around where [MIN,MAX]
> >> degraded into VR_VARYING, then yes.  But alas, we have two ways of
> >> representing the entire domain.  Don't look at me.  That crap was
> >> already there :).
> >>
> >> Another approach would be to call ::set_and_canonicalize() before
> >> checking varying_p() and teach the canonicalize function that [MIN, MAX]
> >> is VR_VARYING.  How does that sound?
> >
> > But that's still broken for the case where it has equivalences.  I fear that
> > if you look at users we'll end up with three or more different
> > varying_p/domain_p
> > things all being subtly different...
>
> Bah, I give up.  I don't have time to look into possible subtleties wrt
> equivalences right now.  I'll drop this patch.
>
> >
> > As said in the other thread we should see to separate equivs out
> > of the way.
>
> And as I meant to say in the other thread, I'll buy you many beers if
> you can do this for this release :).

Well, yall made a mess out of the nicely contained VRP, and topped
it with C++.

Now it's ... a mess.

And for whatever reason all the C++-ification and refactoring had to happen
for GCC 9 :/

> Aldy
Reply | Threaded
Open this post in threaded view
|

Re: implement value_range::domain_p()

Aldy Hernandez-2


On 11/8/18 10:24 AM, Richard Biener wrote:

> On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez <[hidden email]> wrote:
>>
>>
>>
>> On 11/8/18 9:53 AM, Richard Biener wrote:
>>> On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On 11/8/18 9:34 AM, Richard Biener wrote:
>>>>> On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez <[hidden email]> wrote:
>>>>>>
>>>>>> I believe I've seen this idiom more than once.  I know for sure I've
>>>>>> used it in our ssa-range branch :).  I'll hunt for the other uses and
>>>>>> adjust accordingly.
>>>>>
>>>>> domain_p?!  Isn't that the same as varying_p()?  Also
>>>>
>>>> Sigh, yes.  If we kept normalized value_ranges around where [MIN,MAX]
>>>> degraded into VR_VARYING, then yes.  But alas, we have two ways of
>>>> representing the entire domain.  Don't look at me.  That crap was
>>>> already there :).
>>>>
>>>> Another approach would be to call ::set_and_canonicalize() before
>>>> checking varying_p() and teach the canonicalize function that [MIN, MAX]
>>>> is VR_VARYING.  How does that sound?
>>>
>>> But that's still broken for the case where it has equivalences.  I fear that
>>> if you look at users we'll end up with three or more different
>>> varying_p/domain_p
>>> things all being subtly different...
>>
>> Bah, I give up.  I don't have time to look into possible subtleties wrt
>> equivalences right now.  I'll drop this patch.
>>
>>>
>>> As said in the other thread we should see to separate equivs out
>>> of the way.
>>
>> And as I meant to say in the other thread, I'll buy you many beers if
>> you can do this for this release :).
>
> Well, yall made a mess out of the nicely contained VRP, and topped
> it with C++.
>
> Now it's ... a mess.

You wish!  VRP has been a mess for quite a long time.

>
> And for whatever reason all the C++-ification and refactoring had to happen
> for GCC 9 :/

You're gonna absolutely love what we have in store for GCC 10 ;-).

Aldy
Reply | Threaded
Open this post in threaded view
|

Re: implement value_range::domain_p()

Richard Biener-2
On Thu, Nov 8, 2018 at 4:30 PM Aldy Hernandez <[hidden email]> wrote:

>
>
>
> On 11/8/18 10:24 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez <[hidden email]> wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:53 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez <[hidden email]> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 11/8/18 9:34 AM, Richard Biener wrote:
> >>>>> On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez <[hidden email]> wrote:
> >>>>>>
> >>>>>> I believe I've seen this idiom more than once.  I know for sure I've
> >>>>>> used it in our ssa-range branch :).  I'll hunt for the other uses and
> >>>>>> adjust accordingly.
> >>>>>
> >>>>> domain_p?!  Isn't that the same as varying_p()?  Also
> >>>>
> >>>> Sigh, yes.  If we kept normalized value_ranges around where [MIN,MAX]
> >>>> degraded into VR_VARYING, then yes.  But alas, we have two ways of
> >>>> representing the entire domain.  Don't look at me.  That crap was
> >>>> already there :).
> >>>>
> >>>> Another approach would be to call ::set_and_canonicalize() before
> >>>> checking varying_p() and teach the canonicalize function that [MIN, MAX]
> >>>> is VR_VARYING.  How does that sound?
> >>>
> >>> But that's still broken for the case where it has equivalences.  I fear that
> >>> if you look at users we'll end up with three or more different
> >>> varying_p/domain_p
> >>> things all being subtly different...
> >>
> >> Bah, I give up.  I don't have time to look into possible subtleties wrt
> >> equivalences right now.  I'll drop this patch.
> >>
> >>>
> >>> As said in the other thread we should see to separate equivs out
> >>> of the way.
> >>
> >> And as I meant to say in the other thread, I'll buy you many beers if
> >> you can do this for this release :).
> >
> > Well, yall made a mess out of the nicely contained VRP, and topped
> > it with C++.
> >
> > Now it's ... a mess.
>
> You wish!  VRP has been a mess for quite a long time.
>
> >
> > And for whatever reason all the C++-ification and refactoring had to happen
> > for GCC 9 :/
>
> You're gonna absolutely love what we have in store for GCC 10 ;-).

I believe it when I see it.  Oh wait - that was sarcastic!

Richard.

> Aldy