Jeff has mentioned that it'll take a while longer to review the
threader rewrite, so I've decided to make some minor cleanups while he
gets to it.

There are few minor changes here:

1. I've renamed the solver to gimple-range-path.* which expresses
better that it's part of the ranger tools. The prefix tree-ssa-* is
somewhat outdated ;-).

2. I've made the folder a full blown range_query, which can be passed
around anywhere a range_query is accepted.  It turns out, we were 99%
of the way there, so might as well share the same API.  Now users will
be able use range_of_expr, range_of_stmt, and friends.  This can come
in handy when passing a range_query to something like
simplify_using_ranges, something which I am considering for my
follow-up changes to the DOM threader.

3. Finally, I've renamed the class to path_range_query to make it
obvious that it's a range_query object.

There are no functional changes.

Tested on x86-64 Linux.

I will wait on Jeff's review of the tree-ssa-threadbackward.* changes
before committing this.

Aldy

On Fri, Jul 2, 2021 at 3:17 PM Andrew MacLeod <amacleod@redhat.com> wrote:
>
> On 7/2/21 4:13 AM, Aldy Hernandez wrote:
>
> +
> +// Return the range of STMT as it would be seen at the end of the path
> +// being analyzed.  Anything but the final conditional in a BB will
> +// return VARYING.
> +
> +void
> +path_solver::range_in_path (irange &r, gimple *stmt)
> +{
> +  if (gimple_code (stmt) == GIMPLE_COND && fold_range (r, stmt, this))
> +    return;
> +
> +  r.set_varying (gimple_expr_type (stmt));
> +}
>
> Not objecting to anything here other than to note that I think we have cases where there's a COND_EXPR on the RHS of statements within a block.  We're (in general) not handling those well in DOM or jump threading.
>
>
> I guess I can put that on my TODO list :).
>
> note that we are no longer in the days of range-ops only processing...   fold_range handles COND_EXPR (and every other kind of stmt)  just fine.
>
> Andrew