On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez <al...@redhat.com> wrote: > > > > On 11/8/18 9:53 AM, Richard Biener wrote: > > 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... > > 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
