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] |
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()? AlsoSigh, 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] |