This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: implement value_range::domain_p()




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 :).

Aldy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]