Implement {get,set}_range_info() variants that work with value_range's

[Aldy Hernandez]

On 11/8/18 8:59 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez <aldyh@redhat.com> wrote:
>>
>> get/set_range_info() currently returns the extremes of a range.  I have
>> implemented overloaded variants that return a proper range.  In the
>> future we should use actual ranges throughout, and not depend on range
>> extremes, as depending on this behavior could causes us to lose precision.
>>
>> I am also including changes to size_must_be_zero_p() to show how we
>> should be using the range API, as opposed to performing error prone
>> ad-hoc calculations on ranges and anti-ranges.
> 
> Yeah, I've been talking this all along but not being heard...

My girlfriend says I don't listen.  It could be related.

>> Martin, I'm not saying your code is wrong.  There are numerous other
>> places in the compiler where we manipulate ranges/anti-ranges directly,
>> all of which should be adapted in the future.  Everywhere there is a
>> mention of VR_RANGE/VR_ANTI_RANGE in the compiler is suspect.  We should
>> ideally be using intersect/union/may_contain_p/null_p, etc.
> 
> null_p is a bad name btw, I just confused it with empty_p ... (which we have
> as undefined_p).  contains_only_zero_p would be less confusing.

Yes, a horrible name.  I noticed so as I debugged precisely this bit. 
How about zero_p?

Aldy