On 11/8/18 10:24 AM, Richard Biener wrote:
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.
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
