This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: implement value_range::domain_p()
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.
And for whatever reason all the C++-ification and refactoring had to happen
for GCC 9 :/
> Aldy