implement value_range::domain_p()

[Aldy Hernandez]

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

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