On 11/8/18 9:41 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:05 PM Aldy Hernandez <al...@redhat.com> wrote:
On 11/8/18 8:59 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez <al...@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?
Probably the same ambiguous connotation? But yes, way better than null_p.
Well...for starters I started with the nomenclature already in VRP which
was range_is_null.
Also, how is zero_p() ambiguous? We want to know if the range is [0,
0]. That reads pretty obvious to me.
Aldy
