This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Deal with larger anti-ranages in compare_range_with_value
- From: Tom Truscott <trt at unx dot sas dot com>
- To: ja2morri at csclub dot uwaterloo dot ca (James A. Morrison)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 28 Jul 2005 10:44:39 -0400 (EDT)
- Subject: Re: [patch] Deal with larger anti-ranages in compare_range_with_value
> > it looks like the ordinary-range NE test is missing
> > the case of [p,p] != q detected by compare_values (p,q) returning +2
> I'm not quite sure what you mean but in compare_value_with_range at line 1779
> NE_EXPR dealt with nicely for VR_RANGEs.
Sorry, I probably got the line numbers messed up.
The issue is, compare_values (p,q) returns +2 when
it determines that p!=q but cannot determine their order
(otherwise it would return +1 or -1).
The code for EQ_EXPR handles "~[p,p] == q, p != q" on lines 1773..1774
1764 if (comp == EQ_EXPR)
1766 /* EQ_EXPR may only be computed if VR represents exactly
1767 one value. */
1768 if (compare_values (vr->min, vr->max) == 0)
1770 int cmp = compare_values (vr->min, val);
1771 if (cmp == 0)
1772 return boolean_true_node;
1773 else if (cmp == -1 || cmp == 1 || cmp == 2)
1774 return boolean_false_node;
[Aside: the comment on line 1766..1767 is incorrect,
note the `else' that pairs with line 1768]
The code for NE_EXPR does not check for compare_values() returning 2.
What is missing is a check equivalent to:
if (compare_values (vr->min, vr->max) == 0
&& compare_values (vr->min, val) == 2)
> I'm not a fan of trying to squish any of the code in compare_ranges,
Okay, but note the close similarity of the LT/LE and GT/GE coding.
If EQ/NE are not squished, they could still be made more similar.