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