https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131
--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > So I have a VRP patch which gets us to:
>
> /* If the value range is defined by more than one pair,
> try to optimize to a singularity if either
> the first or last pair is a singleton. */
>
> That is if we have:
> a range like: [0, 0][3, 32768][4294934529, +INF]
>
> and we the comparison like `_37 <= 2`
> Since 2 is a value between the first 2 pairs, we can just say this should be
> the same as `_37 == 0` because that is the only value that is valid here.
>
> The same idea happens for the last 2 pairs (and the last pair is a
> singleton).
>
> Also if we only 2 pairs prefer the one which is 0 (since 0 is always
> simplier).
hmm. you should be able to trim out the "untrue" parts of the range. lets see.
do you have the comparison stmt, or is it just an expression?
maybe it doesnt matter. if you know the expression is "_37 <= 2" you can ask
range-ops what the range of _37 is and intessect it with your range, and ask if
the result is a singleton. then this will work for all kinds of things.
the format is
op1_range (result_range, result_type, lhs_range, op2_range)
so it looks like:
range_op_handler handler (LT_EXPR);
if (handler)
{
Value_Range vr(TREE_TYPE (_37));
if (handler->op1_range (vr, TREE_TYPE (_37), bool_one_range, [2,2]))
_37_range.intersect (vr);
}
if (_37.singleton_p ())
blah()
you have a _37_range of [0, 0][3, 32768][4294934529, +INF]
op1_range for [1, 1] = OP1 LT_EXPR [2,2] will return [0,2]
the intersection result will be [0,0]
this would work for any condition/type and both false and true LHS if you
provide [0,0] or [1,1] for the lhs.
in particular this may help with things like x != 15, where the pair that is
relevant to produce a singleton maybe wont be at one end or the other.
poking around for a minute, it looks like simplify_using_ranges from vr_values
calls a routine called test_for_singularity which has never been converted to
multi-ranges. I wonder if reworking it might resolve this class of issues as
well? Eventually we planned to get to simplify_using-ranges and friends, but
it hasnt happened yet
