On 11/08/2018 04:52 AM, Aldy Hernandez 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.
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.
OK pending another round of tests? (As I had tested this patch along
with a whole slew of other upcoming changes ;-)).
I'm all for simplification! :)
I'd love it if the API made it possible to write these expressions
using native operators and intuitive names, without having to worry
about details like what types they are represented in or how to
convert between them. It would be great if a function like
size_must_be_zero_p could be coded along the lines similar to:
return intersect (size, value_range (ssize_type_node) - 0) == 0;
It shouldn't have to twiddle bits to compute the wide_int value
of SSIZE_MAX or wrestle with convertibility warts by calling
build_int_cst and and wide_int_to_tree.
Martin
PS I think we should be able to get close to the syntax above
with a few value_range ctors:
value_range::value_range (tree type_or_expression);