implement value_range::domain_p()

[Richard Biener]

On Thu, Nov 8, 2018 at 4:30 PM Aldy Hernandez <aldyh@redhat.com> wrote:
>
>
>
> On 11/8/18 10:24 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez <aldyh@redhat.com> wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:53 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez <aldyh@redhat.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 11/8/18 9:34 AM, Richard Biener wrote:
> >>>>> On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez <aldyh@redhat.com> 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