Common API for accessing global and on-demand ranges.
This patch provides a generic API for accessing global ranges. It is
meant to replace get_range_info() and get_ptr_nonnull() with one
common interface. It uses the same API as the ranger (class
range_query), so there will now be one API for accessing local and
global ranges alike.
Follow-up patches will convert all users of get_range_info and
get_ptr_nonnull to this API.
For get_range_info, instead of:
if (!POINTER_TYPE_P (TREE_TYPE (name)) && SSA_NAME_RANGE_INFO (name))
get_range_info (name, vr);
...as well as any other of the range_query methods (range_on_edge,
range_of_stmt, value_of_expr, value_on_edge, value_on_stmt, etc).
As per the API, range_of_expr will work on constants, SSA names, and
anything we support in irange::supports_type_p().
For pointers, the interface is the same, so instead of:
else if (POINTER_TYPE_P (TREE_TYPE (name)) && SSA_NAME_PTR_INFO (name))
{
if (get_ptr_nonnull (name))
stuff();
}
One can do:
get_range_query (cfun)->range_of_expr (vr, name, [stmt]);
if (vr.nonzero_p ())
stuff ();
Along with this interface, we are providing a mechanism by which a
pass can use an on-demand ranger transparently, without having to
change its code. Of course, this assumes all get_range_info() and
get_ptr_nonnull() users have been converted to the new API, which
follow-up patches will do.
If a pass would prefer to use an on-demand ranger with finer grained
and context aware ranges, all it would have to do is call
enable_ranger() at the beginning of the pass, and disable_ranger() at
the end of the pass.
Note, that to use context aware ranges, any user of range_of_expr()
would need to pass additional context. For example, the optional
gimple statement (or perhaps use range_on_edge or range_of_stmt).
The observant reader will note that get_range_query is tied to a
struct function, which may not be available in certain contexts, such
as at RTL time, gimple-fold, or some other places where we may or may
not have cfun set.
For cases where we are sure there is no function, you can use
get_global_range_query() instead of get_range_query(fun). The API is
the same.
For cases where a function may be called with or without a function,
you could use the following idiom:
The default range query obtained by get_range_query() is the global
range query, unless the user has enabled an on-demand ranger with
enable_ranger(), in which case it will use the currently active ranger.
That is, until disable_ranger() is called, at which point, we revert
back to global ranges.
We think this provides a generic way of accessing ranges, both
globally and locally, without having to keep track of types,
SSA_NAME_RANGE_INFO, and SSA_NAME_PTR_INFO. We also hope this can be
used to transition passes from global to on-demand ranges when
appropriate.