This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)
   1765     {
   1766       /* EQ_EXPR may only be computed if VR represents exactly
   1767          one value.  */
   1768       if (compare_values (vr->min, vr->max) == 0)
   1769         {
   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)
                return boolean_true_node;

>  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.

Tom Truscott

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]