https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72443
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-07-26
CC| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
It works just fine for unsigned arithmetic - the ~INT_MIN is just from
undefined overflow behavior...
But yes, union_ranges at the moment doesn't try to do anything fancy but
has the "trivial" implementation:
else if (*vr0type == VR_RANGE
&& vr1type == VR_RANGE)
{
/* The result is the convex hull of both ranges. */
if (operand_less_p (*vr0max, vr1min) == 1)
{
/* If the result can be an anti-range, create one. */
if (TREE_CODE (*vr0max) == INTEGER_CST
&& TREE_CODE (vr1min) == INTEGER_CST
&& vrp_val_is_min (*vr0min)
&& vrp_val_is_max (vr1max))
{
so we restrict the anti-range case to when both ends of the ranges are
MIN/MAX. Enhancing this to minimize the number of elements in the result
would be indeed good (though generally we prefer ranges over anti-ranges
due to the weak anti-range handling).
Sth that would greatly simplify VRP (IMHO) is to dump anti-ranges from the
range representation and instead have the lattice value be composed of
the union of two ranges (that's more powerful for ranges _and_ it can
represent all anti-ranges) [just make it the union of N ranges with N
being configurable - it might be possible to ditch equivalences on the
way though they compose the range as intersections of N ranges]
Maybe just split union_ranges into two parts, one where it handles
all the overlap cases and anti-ranges and one where it chooses the
best representation from sth that is the union of N ranges (N <= 4).
Well. Confirmed.
